Conjur - Kubernetes architecture

This topic describes the architecture of a Conjur - Kubernetes integration.

This section applies to Kubernetes implementations, including native Kubernetes, OpenShift, and GKE.

Integration architecture

User applications are deployed in Kubernetes namespaces. You deploy the Conjur Server in its own Kubernetes namespace, or outside of Kubernetes. Applications gain access to Conjur through authenticated login orchestrated by an authentication client.

The following image shows how applications gain access to secrets in Conjur (deployed inside Kubernetes) using the Kubernetes Authenticator Client:

Components in the Conjur-Kubernetesintegration

The following table describes the components in the Conjur - Kubernetes integration:

Type	Component	Description
Conjur namespace	Conjur Server	Supports full read and write operations, as well as management of policies, secrets, and Conjur services.
	Kubernetes/JWT Authenticator	A plugin to the Conjur Server. Enabled as a service to support application pod authentication.
	Conjur Service	Manages access to Conjur.
	Database	The Conjur database. It is installed in a separate pod in the Conjur namespace or externally. External to the cluster is recommended.
Application namespace	Application containers	Your deployed applications.
Application namespace	Kubernetes Authenticator Client (conjur-authn-k8s-client)	Contacts the Kubernetes Authenticator service in the Conjur Server on behalf of your application. The client obtains the access token that allows logging in to Conjur, and writes the token to the shared volume. The Kubernetes Authenticator client is deployed in the same pod with each user application as either a sidecar or init container.
	Shared volume	Provides the Conjur access token to the application.