DEV Community

Cover image for Configuration Management in Kubernetes - ConfigMap & Secrets
SHARON SHAJI
SHARON SHAJI

Posted on

Configuration Management in Kubernetes - ConfigMap & Secrets

#kubernetes #devops #containers #cloudnative

Most Kubernetes failures in real systems are not caused by Pods crashing.

They are caused by bad configuration management.

Wrong URLs, leaked secrets, environment drift, manual edits — these silently break systems.

Kubernetes provides first-class tools to manage configuration properly.

If you ignore them, your cluster will eventually become unmanageable.

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:

  • Code → container image
  • Configuration → Kubernetes resources

This allows:

  • Same image across environments
  • Config changes without rebuilding images
  • Safer secret handling
  • Predictable deployments

Why Configuration Management Is Critical

Without proper configuration management:

  • You rebuild images for every config change
  • Secrets leak into Git repositories
  • Dev, Alpha,UAT,staging, and prod drift apart
  • Rollbacks become painful
  • Debugging becomes guesswork

Kubernetes assumes configuration will change often — images should not.

Configuration vs Code (Key Principle)

Images should be immutable

Configuration should be external

If you violate this rule, Kubernetes loses most of its value.

Configuration Tools in Kubernetes

Kubernetes provides multiple ways to manage configuration:

  1. ConfigMaps – non-sensitive configuration
  2. Secrets – sensitive data
  3. Environment variables
  4. Mounted configuration files
  5. Helm values / Kustomize overlays
  6. 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
Enter fullscreen mode Exit fullscreen mode

Apply it:

kubectl apply -f configmap.yaml
kubectl get configmap app-config
Enter fullscreen mode Exit fullscreen mode

At this point:

  • Kubernetes stores the configuration
  • No pod behavior changes yet

Using ConfigMap as Environment Variables 

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
    - name: app
      image: nginx
      envFrom:
        - configMapRef:
-
Enter fullscreen mode Exit fullscreen mode

Inside the container:

echo $APP_ENV
echo $APP_PORT
Enter fullscreen mode Exit fullscreen mode

Using ConfigMap as Files (then no restart of service to apply) 

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
Enter fullscreen mode Exit fullscreen mode

Files created:

/etc/config/APP_ENV
/etc/config/APP_PORT
/etc/config/LOG_LEVEL
Enter fullscreen mode Exit fullscreen mode

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=
  DB_PASSWORD: cGFzc3dvcmQ=
Enter fullscreen mode Exit fullscreen mode

Create it:

kubectl apply -f secret.yaml
kubectl get secret db-secret
Enter fullscreen mode Exit fullscreen mode

Using Secret in a Pod 

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

Or as files:

volumeMounts:
  - name: secret-volume
    mountPath: /etc/secret
    readOnly: true
volumes:
  - name: secret-volume
    secret:
      secretName: db-secret
Enter fullscreen mode Exit fullscreen mode

ConfigMaps vs Secrets

Feature ConfigMap Secret
Sensitive data ❌ ✅
Base64 encoded ❌ ✅
Access controlled Limited Stronger
Git-friendly ✅ ❌
Use case App config Credentials

Rule of thumb:

If it can hurt you when leaked → use a Secret.

Environment-Based Configuration (Best Practice)

One image, multiple environments:

dev:
  LOG_LEVEL=debug
  DB_HOST=dev-db

prod:
  LOG_LEVEL=info
  DB_HOST=prod-db
Enter fullscreen mode Exit fullscreen mode

Only configuration changes — image stays the same.

Configuration Drift (Real Problem)

Configuration drift happens when:

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

Solution:

  • Store manifests in Git
  • Apply changes declaratively
  • Avoid kubectl edit in production

Common Configuration Management Mistakes

  1. Hardcoding config inside images
  2. Storing secrets in ConfigMaps
  3. Committing secrets to Git
  4. Rebuilding images for config changes
  5. Treating base64 as encryption

These mistakes will hurt you later.

When ConfigMaps & Secrets Are Not Enough

For complex systems, teams use:

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

But ConfigMaps and Secrets are still the foundation.

Final Takeaway

Good configuration management keeps Kubernetes sane

Bad configuration management breaks everything quietly

If you master:

  • ConfigMaps
  • Secrets
  • Environment-based configuration

You eliminate a massive class of production failures.

Say it clearly.

Top comments (0)