Secrets, ConfigMaps and Environment variables

Everyone has to configure their application in the cloud, for example, changing of database host address in production or providing an API key inside the pod or we have to configure our Nginx application when the pod is created so for these type of scenarios Kubernetes have provided these tools which will help when our application size increases.

Most of the time people are tempted to hardcode these references to the application or getting inside the container and setting this all up which is fine when the application size is small, but it becomes unmanageable in large applications.

Secrets in K8s (Kubernetes)

Secrets let us store and manage information, such as API Keys, SSH Keys, OAuth tokens. Kubernetes secrets are by default stored as unencrypted base64-encoded strings for this caution, Kubernetes documentation recommends us encrypt data at rest or configure RBAC rules.

Types of Secret

When creating a secret, we can specify the secret type using the type field. Kubernetes provides several types of common usage scenarios. These types vary in terms of validation performed and constraints imposed on them.

For information regarding how to use these types in detail and their pros and cons please refer to the documentation.

We can use secret with the pod in two ways, As files in a volume mounted in one or more containers, As container environment variable and by kubelet when pulling images for the pod. In this blog, I will be discussing the first two approaches.

So in the first approach first we will create a secret

So let’s now create this secret file using kubectl which will be

“kubectl apply -f secret-file.yaml” after this file is created let’s create the deployment file in which we will mount the volume to the pod than to the specific container

Then apply this deployment file to the cluster using kubectl. After this get into the container with the command “kubectl exec -it (container ID) bin/sh”. Then look for the etc/foo directory you will find the password. file which contains our secret.

The main benefit of using mounted secrets over Using secrets as environment variables is that mounted secrets are updated automatically. The kubelet checks whether the mounted secret is fresh on every periodic sync.

Environment Variables

When we create a pod, we can set environment variables for the container that run in the pod.

If now we get into the container and run echo $GREETING we will get the output “Hello from the environment”

ConfigMaps in Kubernetes

Configmaps is an API object used to store non-confidential data in key-value pairs. Pods can use ConfigMaps as environment variables, command-line arguments, or as configuration files in a volume.

ConfigMap allows us to decouple environment-specific configuration from container images. What if some application requires some configuration file when they start at these kinds of the situation we will use configmaps to provide configuration to the particular application. In secrets, we provide key-value pairs and in configmaps we provide the name of the file with contents in it

Let’s take an example application and in this application, we have to provide a configuration file to the desired application folder and the application will use these configuration files to run.

So first we will create a configuration file config.yaml

And now we will create deployment file temp.yaml

Now apply both configuration file and deployment file “kubectl apply -f config.yaml” and “kubectl apply -f temp.yaml” respectively and now we will get into the container and when we ls into the etc/foo we can see our configuration files.

So most people get confused between the secrets, environment variables and config maps because in small use cases we can use them interchangeably, Kubernetes created these features for specific use cases.

1. Use Secrets for things that are actually secret like API Keys, credentials etc.
2. Use configmaps for not secret configuration data.

Kubernetes also features Immutable Secrets and Immutable ConfigMaps to set individual Secrets and ConfigMaps as immutable. For clusters that extensively use Secrets preventing changes to their data has the following advantages:

• protects you from accidental (or unwanted) updates that could cause applications outages
• improves the performance of your cluster by reducing the load on kube-apiserver, by closing watches for secrets marked as immutable.

Thank You for reading this article, Follow me on Linkedin

Hit Like if you like this article, follow me for more blogs on K8s components and DevOps related articles.