Red Hat OpenShift Container Platform

Understanding secrets

You can mount secrets into containers by using a volume plugin or the system can use secrets to perform actions on behalf of a pod.

The Secret object type provides a mechanism to hold sensitive information such as passwords, Red Hat OpenShift Container Platform client configuration files, private source repository credentials, and so on. Secrets decouple sensitive content from the pods.

Key properties include:

Secret data can be referenced independently from its definition.
Secret data volumes are backed by temporary file-storage facilities (tmpfs) and never come to rest on a node.
Secret data can be shared within a namespace.

YAML Secret object definition

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
  namespace: my-namespace
type: Opaque
data:
  username: <username>
  password: <password>
stringData:
  hostname: myapp.mydomain.com

where:

type: Specifies the structure of the secret’s key names and values.
data: Specifies the allowable format for the keys in the data field must meet the guidelines in the DNS_SUBDOMAIN value as described in "Identifiers and Names in Kubernetes" in the Kubernetes documentation.
data.username: Specifies the value associated with keys in the data map. This value must be base64 encoded.
data.password: Specifies the value associated with keys in the data map. This value must be base64 encoded.
stringData.hostname: Specifies the value associated with keys in the data map. The value associated with keys in the stringData map is made up of plain text strings. Entries in the stringData map are converted to base64 and the entry will then be moved to the data map automatically. This field is write-only; the value will only be returned via the data field.

You must create a secret before creating the pods that depend on that secret.

When creating secrets:

Create a secret object with secret data.
Update the pod’s service account to allow the reference to the secret.
Create a pod, which consumes the secret as an environment variable or as a file (using a secret volume).

Types of secrets

The value in the type field indicates the structure of the secret’s key names and values. The type can be used to enforce the presence of user names and keys in the secret object. If you do not want validation, use the opaque type, which is the default.

Specify one of the following types to trigger minimal server-side validation to ensure the presence of specific key names in the secret data:

kubernetes.io/basic-auth: Use with Basic authentication
kubernetes.io/dockercfg: Use as an image pull secret
kubernetes.io/dockerconfigjson: Use as an image pull secret
kubernetes.io/service-account-token: Use to obtain a legacy service account API token
kubernetes.io/ssh-auth: Use with SSH key authentication
kubernetes.io/tls: Use with TLS certificate authorities

Specify type: Opaque if you do not want validation, which means the secret does not claim to conform to any convention for key names or values. An opaque secret, allows for unstructured key:value pairs that can contain arbitrary values.

You can specify other arbitrary types, such as example.com/my-secret-type. These types are not enforced server-side, but indicate that the creator of the secret intended to conform to the key/value requirements of that type.

For examples of creating different types of secrets, see Understanding how to create secrets.

Secret data keys

Secret keys must be in a DNS subdomain.