This page shows how to securely inject sensitive data, such as passwords and encryption keys, into Pods.
Before you begin
You must have a Kubernetes cluster and the kubectl command-line tool must be configured to communicate with your cluster. We recommend that you run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you don’t already have a cluster, you can create one using minikube or you can use one of these
- Play with Kubernetes
Turn your secret data into a base-64 representation
Suppose you want to have two secret data: a my-app username and a password 39528$vdg7Jb. First, use a base64 encoding tool to convert your user name and password to a base64 representation. Here is an example using the commonly available base64 program:
The output shows that the base-64 representation
of your username is bXktYXBw, and the base-64 representation of your password is Mzk1MjgkdmRnN0pi.
Create a secret
Here is a configuration file that you can use to create a secret that contains your username and password
the secret View information about the Secret:Output:
- NAME TYPE DATA AGE test-secret Opaque 2 1m
more detailed information about Secret
:Output:Name: test-secret Namespace: default Tags: <none> Annotations: <none> Type: Opaque data ==== Password: 13 bytes Username
Create a secret directly with
If you want to skip the Base64 encoding step, you can create the same secret by using the kubectl create secret command. For example:
This is more convenient. The detailed approach shown above walks through each step explicitly to demonstrate what is happening.
Create a Pod that
accesses secret data through a volume
Here is a
configuration file you can use to create
a Pod:Create the Pod:Verify that your Pod is running:
:NAME READY STATE REBOOT AGE secret-test-pod 1/1 Running 0 42m
Get a shell on the container that is running on your Pod:
Secret data is exposed to the container through a volume mounted in /etc/secret-volume.
in your shell list the files in the /
:the output displays two files, one for each piece of secret data
The result is your username and password:
:password username In your shell, display the contents of the username and password files:
Modify your image or command line so that the program searches for files in the mountPath directory. Each key in the secret data map becomes a file name in this directory.
Project secret keys
for specific file
You can also control the paths within the volume where the secret keys are projected. Use
the .spec.volumes.secret.items field to change the destination path of each key:
When you deploy this Pod, the following happens:
The mysecret username key is available to the container in the path /etc/foo/
- my-group/my-username instead of in /etc/foo/username
- The password key for that Secret object is not projected
If you list keys explicitly by using .spec.volumes.secret.items, Please note:
Only the keys specified in the
- items are projected
- keys must exist in the
- corresponding secret. Otherwise, the volume is not created.
. To consume all the keys in the secret, they must all appear in the item field. All listed
Set POSIX permissions for secret
You can set the POSIX file access permission bits for a single secret key. If you do not specify any permissions, 0644 is used by default. You can also set a default POSIX file mode for the entire secret volume, and you can override by key if necessary.
For example, you can specify a default mode like this:
The secret is mounted in /etc/foo; all files created by mounting the secret volume have permission 0400.
Define container environment variables
You can consume Secrets data as environment variables in containers.
If a container
already consumes a secret in an environment variable, the container will not see a secret update unless it is restarted. There are third-party solutions to trigger reboots when secrets change.
Define a container environment variable
with data from a single secret
environment variable as a key-value pair in a
Create the Pod:
In your shell, display the contents of SECRET_USERNAME
container environment variable
The result is
Secret:Map the backend-username value defined in the Secret to the environment variable SECRET_USERNAME in the Pod specification.
Define container environment variables with data from multiple
secrets As in the previous example, create the secrets first
Define the environment variables in the Pod specification.
In your shell, display
the container environment variables
The result is
Configure all key-value pairs in a Secret as container environment variables Create
a secret that contains multiple key-value
pairs Use envFrom to define all Secret’s data as container environment variables. The secret key becomes the name of the environment variable in the pod.
In your shell, display username and password container environment variables
The result is
username: my-app password: 39528$vdg7Jb
- Secret Volume
- more about Secrets. Learn about Volumes.