The Secret
object type provides a mechanism to hold sensitive information such
as passwords, OpenShift client config files, dockercfg
files, private source
repository credentials, 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: (1)
username: "dmFsdWUtMQ0K"
password: "dmFsdWUtMg0KDQo="
-
The allowable format for the keys in the
data
field must meet the guidelines in the DNS_SUBDOMAIN value in the Kubernetes identifiers glossary.
Key properties include:
-
Secret data can be referenced independently from its definition.
-
Secret data never comes to rest on the node. Volumes are backed by temporary file-storage facilities (tmpfs).
-
Secret data can be shared within a namespace.
A secret must be created before the pods that depend on it.
Containers read the secret from the files. If a secret is expected to be stored in an environment variable, then you must modify the image to populate the environment variable from the file before running the main program.
Once a pod is created, its secret volumes do not change, even if the secret
resource is modified. To change the secret used, the original pod must be
deleted, and a new pod (perhaps with an identical PodSpec) must be created. An
exception to this is when a node is rebooted and the secret data must be re-read
from the API server. Updating a secret follows the same workflow as deploying a
new container image. The
kubectl
rollingupdate
command can be used.
The resourceVersion
value in a secret is not specified when it is referenced.
Therefore, if a secret is updated at the same time as pods are starting, then
the version of the secret will be used for the pod will not be defined.
Note
|
Currently, it is not possible to check the resource version of a secret object
that was used when a pod was created. It is planned that pods will report this
information, so that a controller could restart ones using a old
|
When creating secrets:
-
Create a secret object with secret data
-
Create a pod with a volume of type
secret
and a container to mount the volume -
Update the pod’s service account to allow the reference to the secret.
To create a secret object, use the following command, where the json file is a predefined secret:
$ oc create -f secret.json
See Examples.
See Using Image Pull Secrets for more information.
See Using Private Repositories for Builds for more information.
To use a secret, a pod needs to reference the secret. A secret can be used with a pod in two ways: either as files in a volume mounted on one or more of its containers, or used by kubelet when pulling images for the pod.
Volume type secrets write data into the container as a file using the volume mechanism. imagePullSecrets use service accounts for the automatic injection of the secret into all pods in a namespaces.
When a template contains a secret definition, the only way for the template to
use the provided secret is to ensure that the secret volume sources are
validated and that the specified object reference actually points to an object
of type Secret
. Therefore, a secret needs to be created before any pods that
depend on it. The most effective way to ensure this is to have it get injected
automatically through the use of a service account.
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.
apiVersion: v1
kind: Pod
metadata:
name: secret-example-pod
spec:
containers:
- name: secret-test-container
image: busybox
command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ]
volumeMounts:
# name must match the volume name below
- name: secret-volume
mountPath: /etc/secret-volume
readOnly: true
volumes:
- name: secret-volume
secret:
secretName: test-secret
restartPolicy: Never