Chapter 11. Secrets

The Secret object type provides a mechanism to hold sensitive information such as passwords, OpenShift client config files, dockercfg files, etc. Secrets decouple sensitive content from the pods that use it and can be mounted into containers using a volume plug-in or used by the system to perform actions on behalf of a pod. This topic discusses important properties of secrets and provides an overview on how developers can use them.

{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": {
    "name": "mysecret"
  },
  "namespace": "myns",
  "data": { 
    "username": "dmFsdWUtMQ0K",
    "password": "dmFsdWUtMg0KDQo="
    }
}

{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": {
    "name": "mysecret"
  },
  "namespace": "myns",
  "data": { 

    "username": "dmFsdWUtMQ0K",
    "password": "dmFsdWUtMg0KDQo="
    }
}

Key properties include:

When creating secrets:

oc create -f secret.json

$ oc create -f secret.json

Secret volume sources are validated to ensure that the specified object reference points to a Secret object. Therefore, a secret needs to be created before the pods that depend on it.

Secret API objects reside in a namespace. They can only be referenced by pods in that same namespace.

Individual secrets are limited to 1MB in size. This is to discourage the creation of large secrets that would exhaust apiserver and kubelet memory. However, creation of a number of smaller secrets could also exhaust memory.

Currently, when mounting a secret, the service account for a pod must have the secret in the list of mountable secrets. If a template contains a secret definition and pods that consume it, the pods will be rejected until the service account is updated.