CyberArk Secrets Provider for Kubernetes

The topic describes the CyberArk Secrets Provider for Kubernetes.

The Secrets Provider for Kubernetes populates Kubernetes Secrets with secrets stored and managed in Conjur.

Setup options

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

Container type

Description

Init container

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

See Secrets Provider for Kubernetes - Init Container.

Application container

The Secrets Provider for Kubernetes is deployed in its own pod in a namespace, and serves multiple applications or pods that reside in the same namespace.

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

See Secrets Provider for Kubernetes - Application Container.

System requirements

For system requirement, see Requirements.

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

Contribute to the CyberArk Secrets Provider for Kubernetes

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