Workloads in Conjur

Workloads are non-human actors in your environment, for example; applications, containers, CI jobs, scripts, IoT devices, playbooks, virtual machines, services.

Workloads authenticate to Conjur by means of a workload identity so that they can access resources in Conjur such as secrets, or perform other operations such as creating authenticators and roles.

Workload identity in Conjur

This section describes best practices for defining workload identities in Conjur for elements of your workload.

Best practice: Individual identity per workload element

  • From a security assessment perspective, assigning individual identities to each individual element in a workload is considered the most secure approach because:

    • It reduces the attack surface using the least privilege principle by limiting and giving an individual element the minimum level of access or privileges that are needed to complete its task

    • It enables segregation of duties by separating elements in a granular way, ensuring that the element is not given enough privileges to misuse the system it owns and that each element is able to access only the resources it needs, based on different authorization rules

  • When deciding on a security model for your organization, we strongly recommend that you carefully consider all security options. Avoid giving your orchestrator and CI/CD tool privileges, even unintentionally, that could potentially be used to access every secret for every app, service, or infrastructure you deploy

  • The above options assume that an application that is being deployed by a DevOps pipeline is represented in Conjur by its own workload identity

Workload identity types

Tools such as Terraform, Ansible, and Puppet can authenticate to Conjur and request secrets during infrastructure deployment and configuration.

Identity in Conjur: Consider the following when determining how to secure your workflow:

  • Individual identity per workload element (Recommended best practice): Each workload element, for example each Terraform manifest, has its own dedicated, unique workload identity in Conjur. The workload uses this identity to authenticate to Conjur and receive access to secrets based on pre-defined authorization rules.

  • Same workload ID for all elements/modules within the workload (aka All-in-one): All the workload elements, for example all the Terraform manifests used for the same application, use a single workload identity for authenticating to Conjur and accessing secrets. In this case, the same secrets are shared among all the workload elements.

CI/CD pipelines such as Jenkins, GitLab CI, and Azure DevOps can authenticate to Conjur and retrieve secrets when deploying infrastructure or applications/services.

A classic CI/CD workload can be built of many pipelines or other sub-entities.

Identity in Conjur: Consider the following when determining how to secure a CI/CD workflow:

  • Individual identity per workload element (Recommended best practice): Provide each CI/CD pipeline (for example, finance-pipeline-prod, finance-pipeline-stg) with its own unique workload identity to authenticate to Conjur and retrieve secrets. From a Conjur perspective, each pipeline should have a single workload identity.

  • Same workload ID for all elements/modules within the workload (aka All-in-one): Provide the overall CI/CD orchestrator with a single workload identity (for example, a workload identity that represents the Jenkins server) to authenticate to Conjur and retrieve all secrets for all pipelines and deployed applications/infrastructure.

Container orchestration platforms based on Kubernetes, such as Amazon EKS, Microsoft AKS, Google GKE, and self-hosted deployments, can authenticate to Conjur and retrieve secrets.

Classic Kubernetes cluster deployments can have one or more namespaces containing several Pods and containers that, together, represent an application.

Identity in Conjur: Consider the following when determining how to secure a container orchestration platform:

  • Individual identity per workload element (Recommended best practice): Assign identity based on Pod name, controller name (Deployment or StatefulSet), service account, namespace, or namespace labels

  • Same workload ID for all elements/modules within the workload (aka All-in-one): All the Pods authenticate using the same-single identity assigned on the Kubernetes cluster level

Example: Workloads per application

To better understand workloads, let's examine an ERP application that reads and writes data into a database stored on a central SQL server.

The ERP application operates by means of the following workloads:

  • 5 microservices located in different Kubernetes clusters

  • 2 Jenkins pipelines that build the application

  • 2 Terraform scripts that deploy the application’s workloads

Each of these workloads authenticates to Conjur using a different authentication method, and each is authorized to access different resources in Conjur. For example, a workload could be a service account that needs to access the SQL database, or AWS IAM role credentials that have permission to create an EC2 machine.

Workload representation in Conjur

Each workload must prove to Conjur that it is who it says it is, so that it can be authenticated and authorized to access secrets and resources from Conjur.

This is achieved by creating an identity in Conjur that represents the workload: a workload identity. Workload identities are defined as host objects in Conjur policy. Host objects operate using the least set of privileges necessary to complete a job, according to business requirements.

To set up identities for our ERP application's two Jenkins pipelines, here is an example of how the host policy could look:

- !policy
  id: jenkins-prod
  body:
    - !host
      id: ERP-pipeline-prod
      annotations:
        description: Production Jenkins
        authn-jwt/JenkinsAuth_svc_id/jenkins_pronoun: Pipeline
        authn-jwt/JenkinsAuth_svc_id/jenkins_task_noun: Build
        authn-jwt/JenkinsAuth_svc_id/identity: prod-app1

    - !host
      id: ERP-pipeline-prod-infra
      annotations:
        description: Production Jenkins
        authn-jwt/JenkinsAuth_svc_id/jenkins_pronoun: Pipeline
        authn-jwt/JenkinsAuth_svc_id/jenkins_task_noun: Build
        authn-jwt/JenkinsAuth_svc_id/identity: prod-app2