Creating Generic Secrets

Creating secrets#

The major difference is that we specified the type of the Secret as generic.

It could also be docker-registry or tls. We won’t explore those two, but only say that the former can be used to provide kubelet with credentials it needs to pull images from private registries. The latter is used for storing certificates.

In this chapter, we’ll focus on the generic type of secrets which happen to use the same syntax as ConfigMaps.

Just as with ConfigMaps, generic Secrets can use --from-env-file, --from-file, and --from-literal as sources. They can be mounted as files, or transformed into environment variables. Since creating Secrets is so similar to creating ConfigMaps, we won’t go into all the permutations we can do.

For now, we created a Secret called my-creds which holds two literal values.

Working with secrets#

Let’s take a look at the Secrets we now have in the cluster.

The output is as follows.

We can see that the newly created Secret is available and that it has two pieces of data.

JSON Representation#

Let’s see the json representation of the Secret and try to find out how to retrieve it.

The output is as follows (metadata is removed for brevity).

We can see that the data field contains the password and the username. They coincide with the literal values we specified in the command that created the Secret.

Decoding the values#

You’ll notice that the values are “strange”. They are encoded. If we’d like to see the original values we stored as secrets, we’ll need to decode them.

We used jsonpath to filter the output so that only the username data is retrieved. Since the value is encoded, we piped the output to base64 command that decoded it for us. The result is jdoe.

Similarly, the command that will retrieve and decode the second Secret data is as follows.

The output is incognito.

Try it yourself#

A list of all the commands used in the lesson is given below.