CyberArk Secrets Provider for Kubernetes

The topic describes the CyberArk Secrets Provider for Kubernetes.

The Secrets Provider for Kubernetes populates Kubernetes Secrets or a shared volume file with secrets stored and managed in Conjur.

Deployment options

You can set up the Secrets Provider for Kubernetes as follows:

Container type

Description

Sidecar/Init container

The Secrets Provider for Kubernetes is deployed in the same Pod as an application.

With this option, Kubernetes applications can consume Conjur secrets from one or more secrets files accessed through a shared, mounted volume in the same Pod as the application container, or directly from Kubernetes Secrets.

See Secrets Provider - init container/sidecar (cert-based authn).

Application container

The Secrets Provider is deployed in its own Pod in a namespace, and serves multiple applications or Pods that reside in the same namespace.

The Secrets Provider is deployed using the Secrets Provider Helm chart.

See Secrets Provider for Kubernetes - Kubernetes Job - (cert-based authn).

System requirements

For system requirement, see OpenShift/Kubernetes.

Conjur secrets mapped to Kubernetes Secrets - an example

Let's say you have an application that consumes the following Kubernetes Secret, db-credentials:

  
---
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DBName:   bXlhcHBEQg==
  username: dGhlLXVzZXItbmFtZQ==
  password: dGhlLXBhc3N3b3Jk

You determine that the username and password values are sensitive and should be stored in Conjur. You decide that the DBName value is not as sensitive, and can remain in Kubernetes.

To store the sensitive data in Conjur, you define the secrets/username and secrets/password variables in Conjur. You update the original Kubernetes Secret yaml with a mapping to these variables in Conjur, for example:

  
# mysecrets.yml
---
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DBName:   bXlhcHBEQg==
stringData:
  conjur-map: |-   
    username: secrets/username
    password: secrets/password

Conjur secrets mapped to a shared volume mount (aka Push-to-File)

Supported for the Secrets Provider as a sidecar or init container only.

Kubernetes applications can consume Conjur secrets directly through one or more secrets files accessed through a shared, mounted volume.

Providing secrets in this way should require zero application changes, as reading local secrets files is a common, platform-agnostic delivery method.

The Secrets Provider can be configured to create and write multiple secrets files containing Conjur secrets. Each secrets file is configured independently as a group of Kubernetes Pod Annotations, collectively referred to as a "secret group".

For more information about how to set up this deployment method, see Secrets Provider - init container/sidecar - Push-to-File mode.

You can convert existing application deployments that push Conjur secrets to Kubernetes Secrets to push to secrets files instead. For details, see Convert existing Secrets Provider deployments to Push-to-File.

Secrets rotation and updates

When running as a sidecar, the Secrets Provider can support rewriting secrets if their values change. These changes might be as a result of secrets rotation or any other updates to the secrets' values.

For details about secrets rotation, see Secrets rotation.

For details on how to set up the Secrets Provider to run as a sidecar, see Secrets Provider - init container/sidecar (cert-based authn).

Contribute to the CyberArk Secrets Provider for Kubernetes

We welcome contributions. Visit the secrets-provider-for-k8s repo on GitHub.