Managing Secrets using kubectl

Creating Secret objects using kubectl command line.

Before you begin

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using minikube or you can use one of these Kubernetes playgrounds:

Create a Secret

A Secret can contain user credentials required by pods to access a database. For example, a database connection string consists of a username and password. You can store the username in a file ./username.txt and the password in a file ./password.txt on your local machine.

  1. echo -n 'admin' > ./username.txt
  2. echo -n '1f2d1e2e67df' > ./password.txt

In these commands, the -n flag ensures that the generated files do not have an extra newline character at the end of the text. This is important because when kubectl reads a file and encodes the content into a base64 string, the extra newline character gets encoded too.

The kubectl create secret command packages these files into a Secret and creates the object on the API server.

  1. kubectl create secret generic db-user-pass \
  2. --from-file=./username.txt \
  3. --from-file=./password.txt

The output is similar to:

  1. secret/db-user-pass created

The default key name is the filename. You can optionally set the key name using --from-file=[key=]source. For example:

  1. kubectl create secret generic db-user-pass \
  2. --from-file=username=./username.txt \
  3. --from-file=password=./password.txt

You do not need to escape special characters in password strings that you include in a file.

You can also provide Secret data using the --from-literal=<key>=<value> tag. This tag can be specified more than once to provide multiple key-value pairs. Note that special characters such as $, \, *, =, and ! will be interpreted by your shell) and require escaping.

In most shells, the easiest way to escape the password is to surround it with single quotes ('). For example, if your password is S!B\*d$zDsb=, run the following command:

  1. kubectl create secret generic db-user-pass \
  2. --from-literal=username=devuser \
  3. --from-literal=password='S!B\*d$zDsb='

Verify the Secret

Check that the Secret was created:

  1. kubectl get secrets

The output is similar to:

  1. NAME TYPE DATA AGE
  2. db-user-pass Opaque 2 51s

You can view a description of the Secret:

  1. kubectl describe secrets/db-user-pass

The output is similar to:

  1. Name: db-user-pass
  2. Namespace: default
  3. Labels: <none>
  4. Annotations: <none>
  5. Type: Opaque
  6. Data
  7. ====
  8. password: 12 bytes
  9. username: 5 bytes

The commands kubectl get and kubectl describe avoid showing the contents of a Secret by default. This is to protect the Secret from being exposed accidentally, or from being stored in a terminal log.

Decoding the Secret

To view the contents of the Secret you created, run the following command:

  1. kubectl get secret db-user-pass -o jsonpath='{.data}'

The output is similar to:

  1. {"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}

Now you can decode the password data:

  1. # This is an example for documentation purposes.
  2. # If you did things this way, the data 'MWYyZDFlMmU2N2Rm' could be stored in
  3. # your shell history.
  4. # Someone with access to you computer could find that remembered command
  5. # and base-64 decode the secret, perhaps without your knowledge.
  6. # It's usually better to combine the steps, as shown later in the page.
  7. echo 'MWYyZDFlMmU2N2Rm' | base64 --decode

The output is similar to:

  1. 1f2d1e2e67df

In order to avoid storing a secret encoded value in your shell history, you can run the following command:

  1. kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode

The output shall be similar as above.

Clean Up

Delete the Secret you created:

  1. kubectl delete secret db-user-pass

What’s next