Mastering ConfigMaps and Secrets in Kubernetes - A Practical Guide

In Kubernetes, managing application configuration and sensitive data is crucial for maintaining flexible and secure deployments. In this hands-on guide, we’ll explore how to use ConfigMaps and Secrets to inject data into your pods, following the official Kubernetes documentation.

Understanding ConfigMaps and Secrets#

ConfigMaps store non-sensitive configuration data in key-value pairs.
Secrets are similar to ConfigMaps but are intended for storing sensitive information, such as passwords or API keys.

Let’s dive into a practical example of using Secrets to inject sensitive data into a pod.

Step-by-Step Guide: Using Secrets for Secure Data Distribution#

Step 1: Create a Secret#

First, let’s create a Secret containing some sensitive data:

1
kubectl create secret generic db-user-pass \
2
    --from-literal=username=admin \
3
    --from-literal=password=S!B\*d$zDsb=

This command creates a Secret named db-user-pass with two key-value pairs.

Step 2: Verify the Secret#

Check that the Secret was created:

1
kubectl get secrets

You should see db-user-pass in the list.

Step 3: Create a Pod That Uses the Secret#

Now, let’s create a pod that uses this Secret to set environment variables:

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: secret-env-pod
5
spec:
6
  containers:
7
    - name: mycontainer
8
      image: redis
9
      env:
10
        - name: SECRET_USERNAME
11
          valueFrom:
12
            secretKeyRef:
13
              name: db-user-pass
14
              key: username
15
        - name: SECRET_PASSWORD
16
          valueFrom:
17
            secretKeyRef:
18
              name: db-user-pass
19
              key: password
20
  restartPolicy: Never

Save this as secret-env-pod.yaml and apply it:

1
kubectl apply -f secret-env-pod.yaml

Step 4: Verify the Environment Variables#

To verify that the environment variables are set correctly:

1
kubectl exec -it secret-env-pod -- /bin/sh -c 'echo $SECRET_USERNAME && echo $SECRET_PASSWORD'

You should see the values you set in the Secret.

Bonus: Using ConfigMaps#

While we focused on Secrets in this guide, ConfigMaps work similarly for non-sensitive data. Here’s a quick example:

Create a ConfigMap:

1
kubectl create configmap app-config --from-literal=APP_COLOR=blue --from-literal=APP_MODE=prod

Use it in a pod:

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: configmap-demo-pod
5
spec:
6
  containers:
7
    - name: demo
8
      image: alpine
9
      command: ["sleep", "3600"]
10
      env:
11
        - name: APP_COLOR
12
          valueFrom:
13
            configMapKeyRef:
14
              name: app-config
15
              key: APP_COLOR
16
        - name: APP_MODE
17
          valueFrom:
18
            configMapKeyRef:
19
              name: app-config
20
              key: APP_MODE

Key Takeaways#

Separation of Concerns: ConfigMaps and Secrets allow you to separate configuration from application code, making it easier to manage and update.
Security: Secrets provide a way to handle sensitive information more securely than storing it directly in pod specifications or Docker images.
Flexibility: You can use the same ConfigMap or Secret across multiple pods, making it easy to maintain consistent configuration.
Environment Variables: Both ConfigMaps and Secrets can be used to set environment variables in pods, which is a common pattern for application configuration.
Multiple Formats: While we used literal values in our examples, ConfigMaps and Secrets can also be created from files, which is useful for larger configurations.

Conclusion#

ConfigMaps and Secrets are powerful tools in the Kubernetes ecosystem for managing application configuration and sensitive data. By using these resources, you can create more flexible, secure, and maintainable deployments.

As you continue working with Kubernetes, explore other ways to use ConfigMaps and Secrets, such as mounting them as volumes in your pods. Remember, while Secrets provide a more secure way to handle sensitive data compared to ConfigMaps, they are not encrypted by default in etcd. For production environments, consider additional security measures like encryption at rest.

Happy Kuberneting!

Newsletter