Day 6: ConfigMaps and Secrets – Managing Configurations in Kubernetes

Welcome to Day 6 of the Zero to Platform Engineer in 30 Days challenge! Today, we’re focusing on ConfigMaps and Secrets, two essential tools for managing application configurations and sensitive data in Kubernetes.

What Are ConfigMaps and Secrets?

In Kubernetes, ConfigMaps and Secrets allow you to manage configuration and sensitive information separately from your application code.

ConfigMaps

Store non-sensitive configuration data, like environment variables or config files.
Make your applications more flexible and portable.

Secrets

Designed to store sensitive data, such as API keys, passwords, or TLS certificates.
Data is encoded in Base64 for secure storage and transmission.

🎯 Why Separate Configurations? Separating configurations from code enables better portability, security, and easier updates without redeploying your app.

How They Fit Into Platform Engineering

As a Platform Engineer, you’ll often work with ConfigMaps and Secrets to:

Standardize configuration management across environments.
Securely store sensitive data.
Enable dynamic updates without disrupting application runtime.

Hands-On: Working with ConfigMaps and Secrets

Let’s create and use ConfigMaps and Secrets step by step.

Step 1: Create and Use a ConfigMap

Create a file named configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  APP_DEBUG: "false"
  APP_VERSION: "1.0.0"

Apply the ConfigMap:

kubectl apply -f configmap.yaml

Verify the ConfigMap:

kubectl get configmap app-config -o yaml

Use the ConfigMap in a Deployment: Create a file named deployment-configmap.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: configmap-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: configmap-app
  template:
    metadata:
      labels:
        app: configmap-app
    spec:
      containers:
      - name: app-container
        image: nginx
        env:
        - name: APP_ENV
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: APP_ENV
        - name: APP_DEBUG
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: APP_DEBUG

Apply the Deployment:

kubectl apply -f deployment-configmap.yaml

Verify the environment inside the Pod:

kubectl exec -it configmap-app -- printenv APP_ENV

Step 2: Create and Use a Secret

Create a Secret using the Kubernetes CLI:

kubectl create secret generic app-secret \
  --from-literal=DB_PASSWORD=supersecurepassword \
  --from-literal=API_KEY=12345abcd

Verify the Secret:

kubectl get secret app-secret -o yaml

Note: The secret is stored in base64 format.

Use the Secret in a Deployment: Create a file named deployment-secret.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secret-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: secret-app
  template:
    metadata:
      labels:
        app: secret-app
    spec:
      containers:
      - name: app-container
        image: nginx
        env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: DB_PASSWORD
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: API_KEY

Apply the Deployment:

kubectl apply -f deployment-secret.yaml

Verify the environment inside the Pod:

kubectl exec -it secret-app -- printenv DB_PASSWORD

Step 3: Update ConfigMaps and Secrets

ConfigMaps and Secrets can be updated dynamically without restarting your Pods.

Update the ConfigMap:

kubectl edit configmap app-config

Update the Secret:

kubectl delete secret app-secret
kubectl create secret generic app-secret \
  --from-literal=DB_PASSWORD=newpassword

🎯 Pro Tip: Use kubectl rollout restart to restart Pods if updates don’t apply automatically.

Bonus 1: Automate Rollouts with Stakater Reloader

By default, Kubernetes doesn’t restart Pods automatically when you update a ConfigMap or Secret. However, tools like Stakater Reloader can help automate this process by detecting changes and triggering a Pod restart.

What Is Stakater Reloader?

Stakater Reloader is a Kubernetes operator that watches for changes in ConfigMaps and Secrets and automatically rolls out Deployments, StatefulSets, or DaemonSets that reference them.

Managing Secrets Dynamically with External Secrets Operator

When your application requires secrets managed outside Kubernetes (e.g., AWS Secrets Manager, HashiCorp Vault, or Google Secret Manager), the External Secrets Operator simplifies the process by syncing external secrets directly into Kubernetes as Secrets.

What Is External Secrets Operator?

External Secrets Operator bridges external secret management systems with Kubernetes. It:

Syncs secrets from external providers directly into Kubernetes.
Reduces manual secret management.
Enhances security by centralizing secret storage in secure systems.

Activity for Today

Set up Stakater Reloader to automate rollouts for ConfigMaps and Secrets.
Set up External Secrets Operator and sync a secret from an external provider.
Use the synced secret in a Deployment and verify it works.

What’s Next?

Now that you’ve learned about managing configurations and secrets dynamically, it’s time to move to stateful applications and persistent storage in Kubernetes. Stay tuned for Day 7: Persistent Volumes and Persistent Volume Claims!

👉 Check it out here: Zero to Platform Engineer Repository

Feel free to clone the repo, experiment with the code, and even contribute if you’d like! 🚀

Follow the Series!

🎉 Don’t miss a single step in your journey to becoming a Platform Engineer! 🎉

This post is just the beginning. Here’s what we’ve covered so far and what’s coming up next:

👉 Bookmark this blog and check back every day for new posts in the series. 📣 Share your progress on social media with the hashtag #ZeroToPlatformEngineer to connect with other readers!