Blogs

Distribute Credentials Securely Using Secrets – Kubernetes

Posted on by admin

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

Kubernetes games:

  • Killercoda
  • 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

:

Create

the secret View information about the Secret:Output:

  2. NAME TYPE DATA AGE test-secret Opaque 2 1m

    View

  3. more detailed information about Secret

    :Output:Name: test-secret Namespace: default Tags: <none> Annotations: <none> Type: Opaque data ==== Password: 13 bytes Username

    :

    7 bytes

Create a secret directly with

kubectl

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:

  1. Output

    :NAME READY STATE REBOOT AGE secret-test-pod 1/1 Running 0 42m

  3. Get a shell on the container that is running on your Pod:

  4. Secret data is exposed to the container through a volume mounted in /etc/secret-volume.

    in your shell list the files in the /

    etc/secret-volume

    directory

    :the output displays two files, one for each piece of secret data

    5. :password username In your shell, display the contents of the username and password files:

  5. The result is your username and password:

    my-app 39528$vdg7Jb

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

paths

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

    • . To consume all the keys in the secret, they must all appear in the item field. All listed

  • keys must exist in the
  • corresponding secret. Otherwise, the volume is not created.

Set POSIX permissions for secret

keys

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

using secret

data

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

  • Define an

    environment variable as a key-value pair in a

    • Secret:Map the backend-username value defined in the Secret to the environment variable SECRET_USERNAME in the Pod specification.

  • Create the Pod:

  • In your shell, display the contents of SECRET_USERNAME

    container environment variable

    The result is

    backend-admin

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.

    • Create the

  • Pod:

  • In your shell, display

    the container environment variables

    The result is

    DB_USERNAME=db-admin BACKEND_USERNAME=backend-admin

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.

  • Create the

    • Pod:

  • In your shell, display username and password container environment variables

    The result is

    username: my-app password: 39528$vdg7Jb

References

  • Secret Volume
  • Pod

What’s next

Learn

  • more about Secrets. Learn about Volumes.
admin