This topic discusses important properties of secrets and provides an overview on how developers can use them.
The Secret object type provides a mechanism to hold sensitive information such
as passwords, OpenShift Container Platform client configuration files, dockercfg files,
private source repository credentials, and so on. Secrets decouple sensitive
content from the pods. You can mount secrets into containers using a volume
plug-in or the system can use secrets to perform actions on behalf of a pod.
apiVersion: v1
kind: Secret
metadata:
name: test-secret
namespace: my-namespace
data: (1)
username: "dmFsdWUtMQ0K"
password: "dmFsdWUtMg0KDQo="| 1 | 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 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.
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).
You can use the create command to create a secret object from a JSON or YAML file:
$ oc create -f <filename>
When you modify the value of a secret, the value (used by an already running pod) will not dynamically change. To change a secret, you must delete the original pod and create a new pod (perhaps with an identical PodSpec).
Updating a secret follows the same workflow as deploying a new container image.
You can use the kubectl rolling-update command.
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.
|
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
|
See examples of YAML files with secret data.
After you create a secret, you can:
Create the pod to reference your secret:
$ oc create -f <your_yaml_file>.yaml
Get the logs:
$ oc logs secret-example-pod
Delete the pod:
$ oc delete pod secret-example-pod
See Using Image Pull Secrets for more information.
See Source Secrets for more information.
Service serving certificate secrets are intended to support complex middleware applications that need out-of-the-box certificates. It has the same settings as the server certificates generated by the administrator tooling for nodes and masters.
To secure communication to your service, have the cluster generate a signed
serving certificate/key pair into a secret in your namespace. To do this, set
the service.alpha.openshift.io/serving-cert-secret-name to the name you want
to use for your secret. Then, your PodSpec can mount that secret. When it is
available, your pod will run. The certificate will be good for the internal
service DNS name, <service.name>.<service.namespace>.svc.
The certificate and key are in PEM format, stored in tls.crt and tls.key
respectively. The certificate/key pair is automatically replaced when it gets
close to expiration. View the expiration date in the
service.alpha.openshift.io/expiry annotation on the secret, which is in
RFC3339 format.
|
In most cases, the service DNS name
|
Other pods can trust cluster-created certificates (which are only signed for internal DNS names), by using the CA bundle in the /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt file that is automatically mounted in their pod.
The signature algorithm for this feature is x509.SHA256WithRSA. To manually
rotate, delete the generated secret. A new certificate is created.
To use a secret, a pod needs to reference the secret. A secret can be used with a pod in three ways:
to populate environment variables for containers.
as files in a volume mounted on one or more of its containers.
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: Secret
metadata:
name: test-secret
data:
username: dmFsdWUtMQ0K (1)
password: dmFsdWUtMQ0KDQo= (2)
stringData:
hostname: myapp.mydomain.com (3)
secret.properties: |- (4)
property1=valueA
property2=valueB| 1 | File contains decoded values. |
| 2 | File contains decoded values. |
| 3 | File contains the provided string. |
| 4 | File contains the provided data. |
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: NeverapiVersion: v1
kind: Pod
metadata:
name: secret-example-pod
spec:
containers:
- name: secret-test-container
image: busybox
command: [ "/bin/sh", "-c", "export" ]
env:
- name: TEST_SECRET_USERNAME_ENV_VAR
valueFrom:
secretKeyRef:
name: test-secret
key: username
restartPolicy: Never