K8s Storage: Using ConfigMaps, Secrets and ENV variables as Configuration Data Sources.

If you've been reading the previous articles about K8s Storage, then you now that Pods are ephemeral and if we want to save the data they generate, we have to create PersistentVolumeClaims, PersistentVolumes and, in the case of Dynamic Storage Provisioning, StorageClasses.

In this article, we will look at some other K8s native objects that behave much like storage and are used for the purpose of passing configuration data to Pods, also called Configuration-as-Data.

Table of Contents

1. Why should we be concerned about Configuration-as-Data?
2. The different ways of passing configuration data to a Pod:
   1. Demo: Environment Variables into containers
   2. Demo: Secrets Creation and Access
   3. Demo: Passing Secrets to containers as ENV
   4. Demo: Passing Secrets as a Volume
   5. Demo: Pulling a container image from a private container registry
   6. Demo: Creating and using ConfigMaps

The first reason goes back to the basic nature of Pods which is they ARE UNRELIABLE. Pods are ephemral and they can be destroyed at will. If the data needed for configuring these Pods is kept inside them, it will be lost the minute the Pod dies. Therefore, it becomes important to save configuration related data to a K8s object (like a Secret or ConfigMap) or even a non K8s object (like environment variables), and everytime a replica Pod is spun up, we can use the information stored inside this config-data-store to ensure the right values are used.

Another important reason is SECURITY. It makes sense to use K8s objects like ConfigMaps and Secrets to store passwords and other sensitive information. In this way, the container in the Pod does not know the password but can ask for it when needed. If the Pod dies, then it dies but the Secrets and passwords are still present and ready for use for the next replica that spins up.

Once the Pod is up and running, these 2 variables should, in theory, be reflected in the list of environment variables inside the container.

Step 1: Execute the Deployment.

Step 2: Take a peek at the list of environment variables inside the container.

Application developers can be sure that if they refer to these environment variables in their code, they will not face a run time error.

We will create the Secret for this demo using the imperative style (i.e. typing the commands to create a Secret right into the terminal instead of in a YAML manifest).

Step 1: Create the Secret.

• The Secret type is generic because its being created through literal values.

Step 2: Access the Secret.

Using $ kubectl get secrets mysecret, we can display the recently created Secret on the terminal.

To check its content, use $ kubectl describe secret mysecret.

The Secret is base64 encoded and is saved in etcd in the Control Plane, without any sort of default restrictions on who can see it.

Step 3: Check the Secrets contents.

Checking the Secrets content is fairly easy.

Step 1: Create a Deployment using the manifest provided.

Step 2: Exec into the Pod and list all environment variables starting with 'mysecret'.

Secrets can also be passed to Pods and containers in the form of a Volume.

Visually, the state resembles Figure 10 below:

The manifest for the Pod shown in Figure 11 is below:

Step 1: Deploy the Pods using the manifest for this demo.

Step 2: EXEC into the Pod and look for the /etc/appconfig directory in the container.

So far, we've seen the different ways Secrets can be used as a source of data (through environment variables and Volume mounts). Now its time to see another more everyday application for them.

What is a Pod if not an executor of containers? In most demos, the source for containers is the public facing docker hub or other registries that allow unauthenticated access but in a security obsessed world, some may decide to save their containers in private registries. Secrets can be used as the 'authentication' mechanism when containers from such registries are needed.

Step 1: Create a Secret that will hold your registry login (docker hub for this demo).

Step 2: Peek inside private-reg-cred using kubectl describe.

Step 3: Create a Deployment referencing the Secret created in Step 2.

Figure 15 shows the content of the Deployment manifest for this part of the demo:

Step 4: Using kubectl describe, look at the resulting Pods metadata to confirm the image is indeed the one from the private registry.

Once the Deployment manifest has been implemented, we can take a look at the resulting Pods metadata to confirm the image from the private repo was downloaded as expected.

ConfigMaps are like Secrets, the only difference being they are not base64 encoded. It is a collection of key-value pairs that can contain application or environment specific settings. Using ConfigMaps (and Secrets) allows us to decouple configuration and Pods, increasing the portability of our application infrastructure.

Using ConfigMaps made using literals for Pod configurations

Step 1: Create a ConfigMap using literal values passed through command line.

Step 2: Confirm the values stored in the ConfigMap are the ones passed through literals.

Step 3: Deploy Pod using this ConfigMap.

The manifest for a Deployment using cm-from-literals as a source of configuration data is shown below in Figure 19:

Step 4: EXEC into the generated Pod and confirm the contents of cm-from-literals are environment variables.

Using ConfigMaps made using files for Pod configurations

Step 1: Create a ConfigMap using a file.

Step 2: Confirm the values stored in the ConfigMap are the same as those in the file.

Step 3: Deploy Pod using this ConfigMap.

Step 4: EXEC into the Pod to check the contents of container's folder at /etc/appconfig.

I write to remember and if in the process, I can help someone learn about Containers, Orchestration (Docker Compose, Kubernetes), GitOps, DevSecOps, VR/AR, Architecture, and Data Management, that is just icing on the cake.