Secrets and Environment Variables in Kubernetes Pods

Secrets are something related to passwords, tokens, authentication details, etc.

Suppose I have a web application which is connected to a MySQL database. Now if I want to store the password of database, putting it in ConfigMap or in the application code wouldn’t be a good idea.

My Application

Kubernetes secrets are here to solve our problem.

There are two steps involved in working with secrets. First create the secrets and second inject them into pod.

Steps for Secret

How to create secrets in Kubernetes:

There are 2 ways to create secrets:

1. Imperative way: We create generic secret through literal on the CLI.

Imperative way to create secrets

2. Declarative way: Here we create one secret file separately.

We create a YAML file and will store the passwords, host, user, and other environment variables here and encode them.

Declarative Way to create Secrets

We put encoded data in that file for more security — however, you should note that this is NOT encryption. They can still easily be decoded. This will be discussed more at the end.

How to encode data

We can encode data using the below commands:

Suppose DB_Host= mysql and DB_Password= sql123

Encode method:

echo -n 'mysql' | base64 OR echo -n 'sql123' | base64

You will get an encoded string.

How to decode the secret

echo -n 'blxy2=u' | base64 --decode

Where blxy2=u is encoded data.

View Secrets

kubectl to get secrets:

Describe Secrets

kubectl describe secrets

After encoding the secrets, we will inject the secret into a POD.

We will give the reference to the secret YAML file to the pod defintion YAML file.

We create envFrom where we mention the secret reference and secret file metadata name.

Inject secrets in POD

A quick note about Secrets

Remember that secrets encode data in base64 format. Anyone with the base64 encoded secret can easily decode it. As such the secrets can be considered as not very safe.

The concept of safety of the Secrets is a bit confusing in Kubernetes. The Kubernetes documentation page and a lot of blogs out there refer to secrets as a “safer option” to store sensitive data. They are safer than storing in plain text as they reduce the risk of accidentally exposing passwords and other sensitive data. In my opinion it’s not the secret itself that is safe, it is the practices around it.

Secrets are not encrypted, so it is not safer in that sense. However, some best practices around using secrets make it safer. As in best practices like:

• Not checking-in secret object definition files to source code repositories.
• Enabling encryption at Rest for Secrets so they are stored encrypted in etcd.

Also, the way Kubernetes handles secrets. Such as:

• A secret is only sent to a node if a pod on that node requires it.

Kubelet stores the secret into a tmpfs so that the secret is not written to disk storage.

Once the Pod that depends on the secret is deleted, kubelet will delete its local copy of the secret data as well.

Having said that, there are other better ways of handling sensitive data like passwords in Kubernetes, such as using tools like Helm Secrets, HashiCorp Vault.

Other ways to store secrets could be as Volumes.