Configuration Management in Kubernetes - ConfigMap & Secrets

Source: Dev.to

Kubernetes failures in real systems are rarely caused by pods crashing.
More often they stem from bad configuration management—wrong URLs, leaked secrets, environment drift, manual edits—issues that silently break systems.

Kubernetes offers first‑class tools for proper configuration management. Ignoring them makes a cluster unmanageable over time.

This post explains

• What configuration management means in Kubernetes
• Why it is critical
• What tools Kubernetes provides
• Real, simple examples
• Common mistakes to avoid

What Is Configuration Management in Kubernetes?

Configuration management is the practice of separating application behavior from application code.

In Kubernetes terms:

Benefits

• Use the same image across environments
• Change config without rebuilding images
• Safer secret handling
• Predictable deployments

Why Configuration Management Is Critical

Without proper configuration management you end up:

• Rebuilding images for every config change
• Leaking secrets into Git repositories
• Allowing dev, alpha, UAT, staging, and prod to drift apart
• Making rollbacks painful
• Turning debugging into guesswork

Kubernetes assumes configuration will change often—images should not.

Configuration vs. Code (Key Principle)

• Images should be immutable
• Configuration should be external

Violating this rule strips Kubernetes of most of its value.

Configuration Tools in Kubernetes

Kubernetes provides multiple ways to manage configuration:

• ConfigMaps – non‑sensitive configuration
• Secrets – sensitive data
• Environment variables
• Mounted configuration files
• Helm values / Kustomize overlays
• CRDs (advanced use cases)

This post focuses on the core building blocks.

ConfigMaps: Managing Application Configuration

A ConfigMap stores non‑sensitive configuration data as key‑value pairs.

Typical use cases

• Environment name
• Ports
• Feature flags
• Service URLs
• Log levels

Example: ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: production
  APP_PORT: "8080"
  LOG_LEVEL: info

Apply it:

kubectl apply -f configmap.yaml
kubectl get configmap app-config

At this point:

• Kubernetes stores the configuration
• No pod behavior changes yet

Using a ConfigMap as Environment Variables

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - configMapRef:
            name: app-config

Inside the container you can verify:

echo $APP_ENV
echo $APP_PORT

Using a ConfigMap as Files (no pod restart required)

apiVersion: v1
kind: Pod
metadata:
  name: config-file-pod
spec:
  containers:
    - name: app
      image: nginx
      volumeMounts:
        - name: config-volume
          mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

The ConfigMap keys become files:

/etc/config/APP_ENV
/etc/config/APP_PORT
/etc/config/LOG_LEVEL

Secrets: Managing Sensitive Configuration

A Secret stores sensitive data such as:

• Passwords
• API keys
• Tokens
• Certificates

Secrets are base64‑encoded, not encrypted by default.

Example: Secret

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  DB_USER: YWRtaW4=          # "admin"
  DB_PASSWORD: cGFzc3dvcmQ=  # "password"

Create it:

kubectl apply -f secret.yaml
kubectl get secret db-secret

Using a Secret in a Pod

As environment variables

apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - secretRef:
            name: db-secret

As files

apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
spec:
  containers:
    - name: app
      image: nginx
      volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret
          readOnly: true
  volumes:
    - name: secret-volume
      secret:
        secretName: db-secret

ConfigMaps vs. Secrets

Rule of thumb: If it can hurt you when leaked → use a Secret.

Environment‑Based Configuration (Best Practice)

One image, multiple environments:

# dev values
LOG_LEVEL: debug
DB_HOST: dev-db

# prod values
LOG_LEVEL: info
DB_HOST: prod-db

Only the configuration changes — the image stays the same.

Configuration Drift (Real Problem)

Drift occurs when:

• Someone edits live resources manually
• Config differs between environments
• No single source of truth exists

Solution

1. Store manifests in Git (GitOps)
2. Apply changes declaratively (kubectl apply, Argo CD, Flux, …)
3. Avoid kubectl edit in production

Common Configuration Management Mistakes

• Hard‑coding config inside images
• Storing secrets in ConfigMaps
• Committing secrets to Git
• Rebuilding images for config changes
• Treating base64 as encryption

These mistakes will hurt you later.

When ConfigMaps & Secrets Are Not Enough

For complex systems teams often add:

• Helm + values.yaml
• Kustomize overlays
• External secret managers (Vault, AWS Secrets Manager, GCP Secret Manager)
• CRDs for advanced configuration APIs

Even then, ConfigMaps and Secrets remain the foundation.

Takeaway

Good configuration management keeps Kubernetes sane
Bad configuration management breaks everything quietly

Mastering:

• ConfigMaps
• Secrets
• Environment‑based configuration

eliminates a massive class of production failures.