Conjur - Kubernetes architecture

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

Architecture for Conjur - Kubernetes integration

To leverage Conjur in Enterprise Kubernetes environments, you deploy the Conjur Follower inside Kubernetes and configure it to sync with your Conjur cluster. The Conjur cluster is deployed outside of your Kubernetes environment. For details, see Configure the Conjur cluster.

We recommend running Followers inside Kubernetes to allow workloads to leverage Conjur's native cert-based or JWT-base authentication. For more information, see Authentication methods: certificate-based vs JWT -based.

In Kubernetes, the Follower is deployed in its own namespace in the Kubernetes cluster. Workloads (applications) are then deployed in Pods in other namespaces.

Why does the Conjur cluster run outside of the Kubernetes environment?

The Conjur auto-failover functionality provides a small subset of Kubernetes functionality in that it provides application durability in the event of hardware failure.

Applications running inside Kubernetes are designed to be stateless. Stateless applications are easy to scale up and down, move, and reschedule.

The Conjur cluster maintains two layers of state: data, via an internal PostgreSQL instance, and Leader role, via ETCD. Additionally, Conjur also requires some manual configuration to bootstrap a new cluster node. The seed file leverages the established trust of the operator, but is not scalable in a dynamic environment such as Kubernetes.

Components in the Conjur-Kubernetesintegration

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

Type	Component	Description
Conjur cluster deployment	Conjur Leader	An container consisting of the Conjur Server and the PostgreSQL database. By running both processes together in the same container, the database is protected from network attack. The Leader supports full read and write operations to the included PostgreSQL database, as well as management of policies, secrets, and all Conjur services.
Conjur cluster deployment	Conjur Standbys	Conjur Servers that are replicas of the Leader with the ability to become a fully functional Leader if needed.
Follower namespace	Service	A Kubernetes service that load-balances and manages access to the Followers and to the Conjur cluster.
	Followers	Read-only replicas of the Leader. Followers support read requests from workloads, relieving load from the Leader. Followers can be scaled horizontally, so you add Followers to add more read capacity. See Set up Follower
	Kubernetes/JWT Authenticator	A plugin to Conjur. Enabled as a service on the Follower to support application Pod authentication.
Application namespace	Application containers	Your deployed workloads.
	Kubernetes Authenticator Client (conjur-authn-k8s-client)	Contacts the Kubernetes Authenticator service in Conjur on behalf of your workload. 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, either as a sidecar or as an init container.
	Shared volume	A volume to provide the Conjur access token to the workload.