Workloads in Conjur Cloud

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 Cloud by means of a workload identity so that they can access resources in Conjur Cloud such as secrets, or perform other operations such as creating authenticators and roles.

Workload identity in Conjur Cloud

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 Cloud by its own workload identity

Workload types

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 Cloud using a different authentication method, and each is authorized to access different resources in Conjur Cloud. 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 Cloud

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

This is achieved by creating an identity in Conjur Cloud that represents the workload: a workload identity. Workload identities are defined as host objects in Conjur Cloud 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