apiVersion: v1
kind: Secret
metadata:
name: test-secret
namespace: my-namespace
type: Opaque (1)
data: (2)
username: dmFsdWUtMQ0K (3)
password: dmFsdWUtMg0KDQo=
stringData: (4)
hostname: myapp.mydomain.com (5)
Some applications need sensitive information, such as passwords and user names, that you do not want developers to have.
As an administrator, you can use Secret
objects to provide this information without exposing that information in clear text.
The Secret
object type provides a mechanism to hold sensitive information such
as passwords, OpenShift Container Platform client configuration files,
private source repository credentials, and so on. Secrets decouple sensitive
content from the pods. You can mount secrets into containers using a volume
plugin or the system can use secrets to perform actions on behalf of a pod.
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.
Secret
object definitionapiVersion: v1
kind: Secret
metadata:
name: test-secret
namespace: my-namespace
type: Opaque (1)
data: (2)
username: dmFsdWUtMQ0K (3)
password: dmFsdWUtMg0KDQo=
stringData: (4)
hostname: myapp.mydomain.com (5)
1 | Indicates the structure of the secret’s key names and values. |
2 | The allowable format for the keys in the data field must meet the
guidelines in the DNS_SUBDOMAIN value in
the
Kubernetes identifiers glossary. |
3 | The value associated with keys in the data map must be base64 encoded. |
4 | 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. |
5 | The value associated with keys in the stringData map is made up of
plain text strings. |
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).
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/service-account-token
. Uses a service account token.
kubernetes.io/basic-auth
. Use with Basic Authentication.
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 |
For examples of different secret types, see the code samples in Using Secrets.
In 4.11, OpenShift Container Platform is adopting an enhancement from upstream Kubernetes, which enables the LegacyServiceAccountTokenNoAutoGeneration
feature by default. As a result, when creating new service accounts (SA), a service account token secret is no longer automatically generated. Previously, OpenShift Container Platform automatically added a service account token to a secret for each new SA.
However, some features and workloads need service account token secrets to communicate with the Kubernetes API server, for example, the OpenShift Controller Manager. While this requirement will be changed in a future release, it remains in OpenShift Container Platform 4.11. As a result, if you need a service account token secret, you must manually use the TokenRequest API to request bound service account tokens or create a service account token secret.
After upgrading to 4.11, existing service account token secrets are not deleted and continue to function as expected.
In 4.11, service account token secrets still appear to have been automatically generated. Although, instead creating two secrets per service account, OpenShift Container Platform now creates one token, which does not work. In a future release, the number will be further reduced to zero. Note that |
For information about requesting bound service account tokens, see Using bound service account tokens
For information about creating a service account token secret, see Creating a service account token secret.
As an administrator you must create a secret before developers can create the pods that depend on that secret.
When creating secrets:
Create a secret object that contains the data you want to keep secret. The specific data required for each secret type is descibed in the following sections.
apiVersion: v1
kind: Secret
metadata:
name: test-secret
type: Opaque (1)
data: (2)
username: dmFsdWUtMQ0K
password: dmFsdWUtMQ0KDQo=
stringData: (3)
hostname: myapp.mydomain.com
secret.properties: |
property1=valueA
property2=valueB
1 | Specifies the type of secret. |
2 | Specifies encoded string and data. |
3 | Specifies decoded string and data. |
Use either the data
or stringdata
fields, not both.
Update the pod’s service account to reference the secret:
apiVersion: v1
kind: ServiceAccount
...
secrets:
- name: test-secret
Create a pod, which consumes the secret as an environment variable or as a file
(using a secret
volume):
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: (1)
- name: secret-volume
mountPath: /etc/secret-volume (2)
readOnly: true (3)
volumes:
- name: secret-volume
secret:
secretName: test-secret (4)
restartPolicy: Never
1 | Add a volumeMounts field to each container that needs the secret. |
2 | Specifies an unused directory name where you would like the secret to appear. Each key in the secret data map becomes the filename under mountPath . |
3 | Set to true . If true, this instructs the driver to provide a read-only volume. |
4 | Specifies the name of the secret. |
apiVersion: 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: (1)
name: test-secret
key: username
restartPolicy: Never
1 | Specifies the environment variable that consumes the secret key. |
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
name: secret-example-bc
spec:
strategy:
sourceStrategy:
env:
- name: TEST_SECRET_USERNAME_ENV_VAR
valueFrom:
secretKeyRef: (1)
name: test-secret
key: username
1 | Specifies the environment variable that consumes the secret key. |
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. Image pull secrets use service accounts for the automatic injection of the secret into all pods in a namespace.
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 a Secret
object. 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 could exhaust apiserver and kubelet memory. However, creation of a number of smaller secrets could also exhaust memory.
As an administrator, you can create an opaque secret, which allows you to store unstructured key:value
pairs that can contain arbitrary values.
Create a Secret
object in a YAML file on a control plane node.
For example:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque (1)
data:
username: dXNlci1uYW1l
password: cGFzc3dvcmQ=
1 | Specifies an opaque secret. |
Use the following command to create a Secret
object:
$ oc create -f <filename>.yaml
To use the secret in a pod:
Update the pod’s service account to reference the secret, as shown in the "Understanding how to create secrets" section.
Create the pod, which consumes the secret as an environment variable or as a file (using a secret
volume), as shown in the "Understanding how to create secrets" section.
For more information on using secrets in pods, see Understanding how to create secrets.