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
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.
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:
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. |
|
Performance |
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:
|
