🎒 The Secret Locker Room: Kubernetes Configuration Management

Imagine your Kubernetes cluster is a busy school. Every student (pod) needs their own locker to store their stuff. Some lockers hold everyday items anyone can see. Others have combination locks for secret treasures. Let’s explore how Kubernetes manages these lockers!

🗄️ What is Configuration Management?

Think of it like this: Your apps need information to work properly, just like you need your school supplies.

• Some info is normal (like your class schedule) → ConfigMaps
• Some info is secret (like your locker combination) → Secrets

Kubernetes helps you organize and deliver this info to your apps automatically!

📋 ConfigMaps: The Bulletin Board

What Are ConfigMaps?

A ConfigMap is like a public bulletin board in school. Anyone can walk by and read:

• Class schedules
• Lunch menus
• Event announcements

In Kubernetes terms: ConfigMaps store non-sensitive configuration data as key-value pairs.

Creating a ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings
data:
  APP_COLOR: "blue"
  APP_MODE: "production"
  welcome.txt: |
    Hello, welcome to our app!

What’s happening?

• APP_COLOR and APP_MODE are simple key-value pairs
• welcome.txt stores a whole file’s content!

Real-Life Example

Your game app needs to know:

• What theme color to use
• What language to display
• How many lives a player starts with

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-config
data:
  THEME: "dark"
  LANGUAGE: "en"
  STARTING_LIVES: "3"

🔐 Secrets: The Locked Safe

What Are Secrets?

A Secret is like the principal’s safe. Only authorized people get access to:

• Test answers
• Student records
• Emergency contacts

In Kubernetes terms: Secrets store sensitive data like passwords, API keys, and certificates.

Creating a Secret

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=      # base64 encoded
  password: cGFzc3dvcmQ=  # base64 encoded

Important: Values are base64 encoded, not encrypted! It’s like writing in pig latin - hidden from quick glances, but not truly secure.

Easy Way to Create Secrets

kubectl create secret generic db-creds \
  --from-literal=username=admin \
  --from-literal=password=secretpass

Kubernetes handles the encoding for you!

🏷️ Secret Types: Different Locks for Different Doors

Kubernetes has special secret types for common use cases:

graph LR
    A[🔐 Secret Types] --> B[Opaque]
    A --> C[kubernetes.io/tls]
    A --> D[kubernetes.io/dockerconfigjson]
    A --> E[kubernetes.io/basic-auth]
    A --> F[kubernetes.io/ssh-auth]

    B --> B1[Generic secrets<br/>Any key-value data]
    C --> C1[TLS certificates<br/>tls.crt + tls.key]
    D --> D1[Docker registry<br/>Image pull auth]
    E --> E1[Basic auth<br/>username + password]
    F --> F1[SSH keys<br/>ssh-privatekey]

Quick Reference Table

TLS Secret Example

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJ...  # cert
  tls.key: LS0tLS1CRUdJ...  # key

🔒 Immutability: The “No Eraser” Rule

What is Immutability?

Imagine a permanent marker instead of a pencil. Once you write something, you can’t change it.

Why use immutable ConfigMaps/Secrets?

1. Safety: Accidental changes can’t break running apps
2. Performance: Kubernetes doesn’t watch for changes (less work!)
3. Reliability: Your config stays exactly as intended

Making Things Immutable

apiVersion: v1
kind: ConfigMap
metadata:
  name: locked-config
data:
  setting: "important-value"
immutable: true  # 🔒 Cannot be changed!

apiVersion: v1
kind: Secret
metadata:
  name: locked-secret
data:
  api-key: c3VwZXJzZWNyZXQ=
immutable: true  # 🔒 Cannot be changed!

Key Points

• Once immutable: true is set, you cannot edit the data
• To make changes, you must delete and recreate the resource
• The immutable field itself cannot be changed back to false

🌿 Environment Variables in Pods

The Simple Way: env

Your pod can receive config as environment variables - like giving a student their personal instruction sheet.

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:v1
    env:
    - name: DATABASE_URL
      value: "postgres://db:5432"

From ConfigMap

env:
- name: APP_COLOR
  valueFrom:
    configMapKeyRef:
      name: app-settings
      key: APP_COLOR

From Secret

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-credentials
      key: password

Bulk Import with envFrom

Why list items one by one when you can grab everything?

spec:
  containers:
  - name: app
    image: myapp:v1
    envFrom:
    - configMapRef:
        name: app-settings
    - secretRef:
        name: db-credentials

Result: All keys become environment variables automatically!

graph LR
    A[ConfigMap<br/>APP_COLOR=blue<br/>APP_MODE=prod] --> B[Pod]
    C[Secret<br/>DB_USER=admin<br/>DB_PASS=****] --> B
    B --> D[Container sees:<br/>APP_COLOR<br/>APP_MODE<br/>DB_USER<br/>DB_PASS]

📁 Config Volume Mounts: Files Instead of Variables

When Files Beat Variables

Sometimes your app expects a config file, not environment variables. Volume mounts deliver config as actual files!

Mounting a ConfigMap as Files

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: app
    image: myapp:v1
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-settings

What happens:

• Each key becomes a file
• File contents = the value
• /etc/config/APP_COLOR contains “blue”

Mounting Secrets as Files

spec:
  containers:
  - name: app
    image: myapp:v1
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
      readOnly: true  # 👈 Good practice!
  volumes:
  - name: secret-volume
    secret:
      secretName: db-credentials

Mount a Single File

Don’t want all keys? Pick just one:

volumes:
- name: config-volume
  configMap:
    name: app-settings
    items:
    - key: welcome.txt
      path: greeting.txt

This mounts only welcome.txt as /etc/config/greeting.txt.

graph TD
    A[ConfigMap] --> B[Volume]
    B --> C[Container]
    C --> D["/etc/config/APP_COLOR"]
    C --> E["/etc/config/APP_MODE"]
    C --> F["/etc/config/welcome.txt"]

⚖️ ConfigMap vs Secret: When to Use What

The Decision Tree

graph TD
    A{Is the data<br/>sensitive?} -->|Yes| B[Use Secret 🔐]
    A -->|No| C[Use ConfigMap 📋]
    B --> D{What type<br/>of secret?}
    D -->|Password/Key| E[Opaque]
    D -->|TLS Cert| F[kubernetes.io/tls]
    D -->|Docker Auth| G[kubernetes.io/dockerconfigjson]

Side-by-Side Comparison

Best Practices

ConfigMaps:

• ✅ Application settings
• ✅ Feature flags
• ✅ Config files (nginx.conf, etc.)
• ✅ Non-sensitive URLs

Secrets:

• ✅ Database passwords
• ✅ API keys and tokens
• ✅ TLS certificates
• ✅ SSH keys
• ✅ OAuth credentials

Security Warning

Secrets are NOT encrypted by default! They’re just base64 encoded (easy to decode).

For true security:

1. Enable encryption at rest in etcd
2. Use RBAC to limit access
3. Consider tools like HashiCorp Vault or Sealed Secrets

🎯 Putting It All Together

Here’s a complete example using everything we learned:

# ConfigMap for app settings
apiVersion: v1
kind: ConfigMap
metadata:
  name: webapp-config
data:
  LOG_LEVEL: "info"
  FEATURE_FLAGS: "new-ui,dark-mode"
---
# Secret for sensitive data
apiVersion: v1
kind: Secret
metadata:
  name: webapp-secrets
type: Opaque
data:
  DB_PASSWORD: cGFzc3dvcmQxMjM=
  API_KEY: YWJjZGVmMTIzNDU2
---
# Pod using both
apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: app
    image: webapp:v2
    # Environment variables
    envFrom:
    - configMapRef:
        name: webapp-config
    env:
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
          name: webapp-secrets
          key: DB_PASSWORD
    # Volume mounts
    volumeMounts:
    - name: secret-files
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secret-files
    secret:
      secretName: webapp-secrets

🌟 Key Takeaways

1. ConfigMaps = Public bulletin board (non-sensitive data)
2. Secrets = Locked safe (sensitive data, base64 encoded)
3. Secret types help Kubernetes validate your data format
4. Immutability prevents accidental changes
5. Environment variables inject config directly into processes
6. Volume mounts deliver config as files
7. Choose wisely: ConfigMap for settings, Secret for passwords

Remember: In the school of Kubernetes, ConfigMaps are your open lockers, and Secrets are the combination-locked safes. Both help keep your apps organized and running smoothly! 🎓

🔑 Quick Commands Reference

# Create ConfigMap from literal
kubectl create configmap my-config \
  --from-literal=key1=value1

# Create ConfigMap from file
kubectl create configmap my-config \
  --from-file=config.txt

# Create Secret from literal
kubectl create secret generic my-secret \
  --from-literal=password=secret123

# View ConfigMap
kubectl get configmap my-config -o yaml

# View Secret (still encoded)
kubectl get secret my-secret -o yaml

# Decode Secret value
kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d

Now you’re ready to manage configuration like a Kubernetes pro! Your apps will always have exactly the settings they need, stored safely and delivered efficiently. 🚀