Authenticate OpenShift/Kubernetes

The OpenShift/Kubernetes integration with Conjur requires some initial setup tasks before workloads can authenticate Conjur to retrieve secrets.

These tasks require Conjur admin and Kubernetes admin permissions.

If you are an application owner, see App owner: Set up workloads in Kubernetes.

  • Unless specifically noted otherwise, all references to Kubernetes apply to Self-hosted Kubernetes as well as Red Hat OpenShift and other supported Kubernetes-based implementations.
  • All references to Kubernetes namespaces intentionally include the OpenShift concept of project.

Setup flow

Assuming you have environment outside of Kubernetes that is already hosting an up-and-running Conjur cluster, you need to set up Followers and your Kubernetes workloads to retrieve secrets from Conjur.

Followers can run inside or outside the Kubernetes environment. Followers outside Kubernetes require a regular Follower deployment.

However, to leverage Conjur in Kubernetes environments, we recommend deploying the Follower inside your Kubernetes cluster. The Follower inside Kubernetes requires an authentication endpoint so that it can authenticate to Conjur.

App owners also need to include an authentication endpoint in the workload deployment manifest.

Authentication methods: certificate-based vs JWT-based

Workloads in Kubernetes that need to retrieve secrets stored in Conjur must authenticate to Conjur before they can retrieve the secrets.

The Conjur-Kubernetes integration supports both certificate (cert)-based and JWT-based authentication to Conjur. Some supported workload setup methods support only one authentication type, such as the Conjur Provider for Secrets Store CSI Driver, which only supports JWT-based authentication.

Before you start setting up the integration, choose the authentication method that best suits your organization's dependencies on the supported Kubernetes vendors, performance, level of granularity that can be accomplished between identities, and more.

Examine some of these dependencies so that you can easily decide which authentication method is more suitable for your organizational needs:

Supported Kubernetes vendors

Conjur supports JWT-based authentication and cert-based authentication for the following Kubernetes vendors:

  • Kubernetes Self-hosted (On-prem or cloud deployment)

  • OpenShift

  • Google Kubernetes Engine (GKE)

  • Azure Kubernetes Service (AKS)

  • Amazon Elastic Container Service for Kubernetes (EKS)

For information about the supported versions, see Supported Kubernetes-based environments.

Identity characteristics

Different levels of granularity can be achieved by each authentication method.

JWT-based authentication can be achieved based on claims provided as part of the service account token which is a JWT. For Kubernetes service account tokens, the namespace and serviceaccount are the primary claims that can be used to authenticate resources.

Cert-based authentication is more appropriate for authenticating resources based on other properties such as Deployment, Pod, or StatefulSet.

For further comparison, see Authenticate OpenShift/Kubernetes.


As part of the cert-based authentication process, Conjur performs several calls to the Kubernetes cluster API to perform the authentication process on behalf of the workload.

In comparison, the JWT-based authentication logic is more efficient and requires fewer calls to the Kubernetes cluster. Conjur performs only one call to the JWKS endpoint. Moreover, depending on the configuration, Conjur might not need to access the JWKS endpoint at all.

For this reason, performance is usually better when using JWT-based authentication over cert-based authentication.

However, performance also depends on your network configuration, available resources, and other applications running in the background, and might differ from one cluster to another.

Setup, configuration, and maintenance

JWT-based authentication configuration is more straight forward in high-scale deployments than cert-based authentication, and reduces the need for special privileges.

Maintenance efforts for each method would depend on your organization's standards:

  • Service account tokens (JWTs) are signed, and their signing keys require management

  • Certificate must be managed, rotated, and stored securely

Set up an authentication endpoint