Kubernetes – Secrets

Kubernetes – Secrets

February 25, 2019 1 By Eric Shanks

Secret, Secret, I’ve got a secret! OK, enough of the Styx lyrics, this is serious business. In the previous post we used ConfigMaps to store a database connection string. That is probably not the best idea for something with a sensitive password in it. Luckily Kubernetes provides a way to store sensitive configuration items and its called a “secret”.

Secrets – The Theory

The short answer to understanding secrets would be to think of a ConfigMap, which we have discussed in a previous post in this series, but with non-clear text.

ConfigMaps would be good to store configuration data that is not sensitive. If it is sensitive information that not everyone should see, then a “secret” should be chosen over a ConfigMap. Password, keys, or private information should be stored as a secret instead of a ConfigMap.

One thing to note is that secrets can be stored a either “data” or “stringData” maps. Data would be used to store a secret in base64 format which you would provide. You can also use stringData which you’d provide an unencoded string but it would be stored as a base64 string when the secret is create. This is a valuable tool when your deployment creates a secret as part of the build process.

Secrets – In Action

Since a secret is just a more secured version of a ConfigMap, the demo will be the same as the last post, with the exception that we’ll use a secret over a ConfigMap to store our connection string. This is a better way to store a connection string over a ConfigMap because it does have a password in it which should be protected.

First, we’ll deploy the database container and service. The database container has already been configured with new database with the appropriate username and password. The manifest file to deploy the DB and service is listed below.

We’ll deploy a new secret from a manifest after we take our connection string and convert it to base64. I took the following connection string:

then ran it through a bash command of:

I took the result of that command and placed int in the Secret manifest under the db.string map.

Deploy the secret via a familiar command we’ve used for deploying our manifests.

Now that the secret is deployed, we can deploy our application pods which will connect to the backend database just as we did with a ConfigMap in a previous post. The important difference between the Deployment manifest using a ConfigMap and the Deployment manifest using a secret is this section.

The full deployment file that will read from the secret and use that secret is listed below.

Deploy the manifest using:

The result is that the app reads from the secret file, and uses that string as part of the connection to the backend database.


Sometimes you’ll want to store non-sensitive data and a ConfigMap is the easy way to store that data. In other cases, the data shouldn’t be available to everyone, like in the case of a password or a connection string. When those situations occur, a secret may be your method to store this data.