OpenShift Secrets Concepts

External

• https://docs.openshift.com/container-platform/latest/dev_guide/secrets.html
• https://kubernetes.io/docs/concepts/configuration/secret/
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/secrets.md
• https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/
• https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

Internal

• OpenShift Security Concepts

Overview

A secret is a piece of text or binary data, associated with a name. OpenShift offers a "Secret" primitive, that can be created and managed independently of any other primitives, then associated with a pod in such a way that the name/data is exposed, or "delivered" to the pod. This approach is convenient when dealing with confidential data that should not be stored in the images the pods are created from.

For more details on the "Secret" primitive definition see:

Secret Definition

OpenShift uses secrets routinely to hold keys for authentication to other internal systems like Docker registries.

The secrets are stored in a base64-encoded format, and delivered to pods as content of volumes or environment variables. Secrets from builds can also be referenced.

By default, every container is given a single secret which contains a token for accessing the API with limited privileges, at /var/run/secrets/kubernetes.io/serviceaccount.

An Example

A simple example of how to expose a name/value pair as a "secret" involves creation of the secret in the target project, then expose the secret to the pods created within the project by associating the secret with the deployment configuration that controls the pod creation.

One way to create a secret is to store the content into a file, and then use the file to create the secret via CLI:

echo "passwd123" > ./db-passwd

oc secret new db-password-secret ./db-passwd

This is a terse syntax, where the name of the key associated with the confidential data is inferred from file name. More flexible syntax variants are available.

The secret thus created (secret/db-password-secret) is represented as:

apiVersion: v1
kind: Secret
metadata:
  name: db-password-secret
  ...
type: Opaque
data:
  db-passwd: cGFzc3dkMTIzCg==

Once declared, the name/confidential value can be exposed to a pod, by associating the secret with the deployment configuration that creates the pod. The data can be exposed as a file, using the volume mechanism, or as an environment variable.

This is how the secret data is exposed as a volume, which is visible as a file to the processes running in pods:

oc set volume dc/<deployment-config-name> --add --name=db-password-volume --mount-path=/etc/secrets --secret-name=db-password-secret

After the pod gets redeployed as result of the configuration change, the volume is mounted as "tmpfs":

tmpfs on /etc/secrets type tmpfs (rw,relatime,seclabel)

The confidential data is available as the /etc/secrets/db-password file:

cat /etc/secrets/db-passwd
passwd123

More details on volume operations are available here:

oc set volumes

This is how the secret data is exposed as an environment variable.

oc env dc/<deployment-config-name> --from=secret/db-password-secret --prefix=BLUE_

env | grep BLUE
BLUE_DB_PASSWD=passwd123

Secret Types

Basic Auth

A secret containing the user name and the password to use in HTTP basic authentication.

Basic Auth Secret Creation and Usage

Operations

Secret Operations

Organizatorium

• Difference from a ConfigMap.
• Accessibility: not encrypted, base64 - how can it be protected?