Conjur Kubernetes Follower

This topic provides an overview of how to deploy the Conjur Kubernetes Follower in OpenShift and other supported Kubernetes environments. The Conjur Kubernetes Follower is a collection of microservices that run as separate containers within a Pod and, together, provide a scalable way to access the secrets stored in Conjur.

For all the options for deploying Followers for the OpenShift/Kubernetes integration, see Deploy Follower for OpenShift/Kubernetes integration.

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.

Overview

Followers are read-only replicas of the Conjur Leader. They can be spun up as needed to handle the load from delivering secrets to a large number of applications. Because Followers are read-only, they can be terminated without concern for data loss.

The Conjur Kubernetes Follower is unique in that:

It is defined and configured as a Kubernetes API resource.
In OpenShift, the Conjur Kubernetes Follower can be deployed by the Conjur Follower Operator. The Operator can be installed using the OpenShift OLM (OpenShift only) or by manual deployment.

In other Kubernetes environments, the Conjur Kubernetes Follower is deployed using a manually installed Operator.
It is a collection of microservices that run as separate containers within a Pod and, together, provide a scalable way to access the secrets stored in Conjur. Each Follower service is a separate microservice Pod provisioned within a Kubernetes Deployment. This allows Conjur Kubernetes Follower instances to be easily scaled up and down to match capacity with usage.
For compatibility with environments that impose security restrictions, such as OpenShift, each service container runs as an unprivileged (non-root) user.

Conjur Kubernetes Follower architecture

This section describes:

Architecture of the Conjur Kubernetes Follower
Kubernetes resources that exist at the namespace level, and through into the pod level.

Namespace-level resources

The following resources must be created inside the namespace where the Conjur Kubernetes Follower is deployed:

Resource	Resource name	Description
ServiceAccount	`ServiceAccount`	Used to authenticate the Conjur Kubernetes Follower with the Conjur Leader. Also used to grant the Conjur Kubernetes Follower permissions in Kubernetes to authenticate applications in other Kubernetes namespaces. For more information about enrolling applications to use the Conjur Kubernetes Follower in Kubernetes, see App owner: Set up workloads in Kubernetes.
Service	`Service`	Makes the Follower API available to applications inside (and optionally outside) the Kubernetes cluster. The service routes requests to the Conjur Kubernetes Follower service Pods and load balances among them when scaled to multiple Pods.
Deployment	`Deployment`	Defines the template for a Conjur Kubernetes Follower Pod, its data storage, its container, and its lifecycle. As a Conjur Kubernetes Follower instance is scaled up and down, this translates into Pods being created and destroyed according to the `Deployment` template. See also: Deployment.

Resource

Resource name

Description

ServiceAccount

ServiceAccount

Used to authenticate the Conjur Kubernetes Follower with the Conjur Leader.

Also used to grant the Conjur Kubernetes Follower permissions in Kubernetes to authenticate applications in other Kubernetes namespaces. For more information about enrolling applications to use the Conjur Kubernetes Follower in Kubernetes, see App owner: Set up workloads in Kubernetes.

Service

Service

Makes the Follower API available to applications inside (and optionally outside) the Kubernetes cluster. The service routes requests to the Conjur Kubernetes Follower service Pods and load balances among them when scaled to multiple Pods.

Deployment

Deployment

Defines the template for a Conjur Kubernetes Follower Pod, its data storage, its container, and its lifecycle.

As a Conjur Kubernetes Follower instance is scaled up and down, this translates into Pods being created and destroyed according to the Deployment template.

See also: Deployment.

Deployment

The Conjur Kubernetes Follower Deployment resource in Kubernetes defines the template for a Conjur Kubernetes Follower Pod, its data storage, its container, and its lifecycle.

Containers

Container	Description
Configurator	Initializes the other containers that make up the Conjur Kubernetes Follower. Uses configuration details retrieved from the Conjur Leader in a file called a seed file. Responsible for connecting to a Leader and retrieving a Conjur Kubernetes Follower seed through the Seed Service API. It then unpacks the seed file into memory volumes that can be shared with the other Conjur Kubernetes Follower containers as needed.
Conjur	A secrets vault. Uses a system of role-based access control defined in declarative policy files to authenticate identities (human or non-human) and authorize them to access the secrets they need. Also generates audit events when a privileged action occurs.
PostgreSQL	A read-only replica of the Conjur Leader database that provides the data store for the Conjur Kubernetes Follower. On startup, this container connects to the Leader over port 5432 and replicates the Leader database. It then continues to receive updates via asynchronous log shipping from the Leader.
syslog-ng	Responsible for forwarding audit events to the Conjur Leader. Audit events are received from Conjur through a Unix socket on a memory volume shared with the Conjur container. The syslog-ng container forwards any audit events to the Leader over port 1999 where they are recorded in a centralized audit log.
NGINX	Functions as a TLS termination proxy for all incoming traffic. Decrypts incoming requests before forwarding them to the Conjur container, and encrypts the outgoing response.
Info	Provides basic information about the Conjur Kubernetes Follower, including the software versions, the Conjur Leader hostname, and available authenticators.

Volumes

Volume	Description
Data key	The Conjur Kubernetes Follower includes a replica of the Conjur Leader database and its secrets. These secrets are encrypted with a secret data protection key. This key must be retrieved from the Leader by the Configurator and then shared with Conjur through a memory volume so that Conjur can decrypt these columns.
Certificates	Includes a server certificate and private key used for TLS connections for the Follower API. They are also used for establishing mutual TLS connections to the Leader for secret replication and audit forwarding. This volume also includes the CA certificate for Conjur used to verify connections to the Leader.
Configuration	Includes all other non-sensitive configuration settings from the Conjur Kubernetes Follower seed file for the Follower services.
Audit	Conjur sends audit events to syslog-ng through a Unix socket on a memory volume that is shared with both the Conjur API and syslog-ng containers.

Conjur Kubernetes Follower initialization and secret retrieval

This section describes the initialization process of the Conjur Kubernetes Follower after it has been deployed. Once it is initialized, the Conjur Kubernetes Follower can retrieve secrets for applications.

Initialization

After deployment, the Conjur Kubernetes Follower must be initialized before it can retrieve secrets.

The Conjur Kubernetes Follower is initialized using a seed file provided by an associated Leader. The seed file contains

certificates used to establish TLS connections with the Leader
an encryption key that the Conjur Kubernetes Follower uses to read encrypted data replicated from the Leader's database.

The following image shows the process of retrieving and unpacking the seed file and replicating the Leader database.

On Pod startup, the Configurator init container authenticates to the Conjur Leader. It then uses the Seed Service API to retrieve a Conjur Kubernetes Follower seed that is used to initialize a Conjur Kubernetes Follower.
The Configurator container unpacks the Conjur Kubernetes Follower seed and stores the relevant pieces in memory volumes that are shared with other containers. At this point, the Configurator container shuts down and the other containers in the Pod start up.
The other containers in the Pod read the seed file it needs from the volumes that have been shared with them, and proceed to initialize themselves.
The PostgreSQL container performs a replication against the Conjur Leader database.

Secret retrieval

This section describes the most common use-case for a Conjur Kubernetes Follower: an application retrieving a secret value. Let's assume the application has already authenticated to Conjur to receive an access token.

An application makes a TLS request against the NGINX container to try and retrieve a secret from the Conjur Kubernetes Follower. It presents a valid Conjur access token obtained from an earlier authentication.
The NGINX container decrypts the TLS request and forwards it to the Conjur container.
Conjur reads the secret value from the PostgreSQL service.
Conjur creates an audit event and writes it to syslog-ng through the audit socket memory volume. The syslog-ng container receives the event and forwards it to the Conjur Leader.
Conjur verifies the access token, requests and retrieves the secret value from the PostgreSQL database, and packages it into a response.

Deploy the Conjur Kubernetes Follower

See Deploy Conjur Kubernetes Follower.