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 deploy 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 secrets from Conjur 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.

For more information, see Secrets Provider - Init container/Sidecar (JWT-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.

For more information, see Secrets Provider for Kubernetes - Kubernetes Job (JWT-based authn).

System requirements

For system requirements, see Supported Kubernetes-based environments.

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.yaml
---
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  DBName:   bXlhcHBEQg==
stringData:
  conjur-map: |-   
    username: secrets/username
    password: secrets/password

For more information about how to set up the Secrets Provider to consume Kubernetes Secrets, see Secrets Provider - init container/sidecar - Kubernetes Secrets mode (JWT-based authn).

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

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

Kubernetes applications can consume secrets in Conjur 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 secrets from Conjur. 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 the Secrets Provider to consume secrets through secrets files, 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 - Push-to-File mode.

Contribute to the CyberArk Secrets Provider for Kubernetes

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