How do ConfigMaps and Secrets work for injecting configuration into workloads?

Question

IT Interview Practice · Accepted Answer

**ConfigMaps** and **Secrets** decouple configuration from container images, so the same image runs in dev, staging, and production with different settings. ConfigMaps hold **non-sensitive** config; Secrets hold **sensitive** data (passwords, tokens, keys) and are handled more carefully.

## The idea: config out of the image

```text
Image = code (immutable, built once).  Config = per-environment values.
Baking config into the image is an anti-pattern (rebuild per env, secrets leak).
→ Store config in ConfigMaps/Secrets, inject at runtime as env vars or files.
```

## ConfigMap: non-sensitive settings

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  FEATURE_X: "true"
  app.properties: |
    timeout=30
    retries=3
```

## Secret: sensitive values

```yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:            # plaintext here; stored base64-encoded in etcd
  DB_PASSWORD: "s3cr3t"
  DB_USER: "appuser"
```

```bash
# Usually created imperatively to avoid committing secrets to git:
kubectl create secret generic db-secret \
  --from-literal=DB_USER=appuser --from-literal=DB_PASSWORD=s3cr3t
```

## Injecting into a Pod: as env vars or as files

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      env:
        - name: LOG_LEVEL                 # single key from a ConfigMap
          valueFrom:
            configMapKeyRef: { name: app-config, key: LOG_LEVEL }
        - name: DB_PASSWORD               # single key from a Secret
          valueFrom:
            secretKeyRef: { name: db-secret, key: DB_PASSWORD }
      envFrom:
        - configMapRef: { name: app-config }   # import ALL keys as env vars
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config           # mount config as files
  volumes:
    - name: config-vol
      configMap: { name: app-config }
```

## Important caveats about Secrets

```text
⚠ Secret data is base64-ENCODED, not encrypted, by default.
  → Enable ENCRYPTION AT REST for etcd (EncryptionConfiguration).
  → Restrict access with RBAC (who can 'get secrets').
  → Prefer external managers (Vault, cloud Secrets Manager) or sealed secrets.
  → Never commit real Secret manifests to git.
Env-var config is read ONCE at container start; mounted files can update live.
```

## Why it matters

Separating configuration from code is a core operational practice, and ConfigMaps and Secrets are how Kubernetes implements it, so understanding them is essential middle-level knowledge. Baking environment-specific settings into an image is an anti-pattern — it forces a rebuild per environment and risks leaking secrets — so Kubernetes lets you keep a single immutable image and inject configuration at runtime: **ConfigMaps** for non-sensitive values (log levels, feature flags, config files) and **Secrets** for sensitive data (passwords, tokens, keys). Knowing the two ways to consume them — as **environment variables** (individual keys via `configMapKeyRef`/`secretKeyRef`, or all keys via `envFrom`) and as **mounted files** (with the nuance that env vars are read once at startup while mounted files can update live) — is everyday practical knowledge for deploying real applications. Equally important is understanding the security caveats that trip up many engineers: Secret data is only **base64-encoded, not encrypted**, by default, so genuinely protecting it requires enabling **encryption at rest** for etcd, restricting access with **RBAC**, avoiding committing Secret manifests to version control, and often integrating an external secret manager. Because virtually every workload needs per-environment configuration and credentials, and because mishandling Secrets is a common and serious security gap, a solid grasp of ConfigMaps and Secrets is fundamental to running applications safely and correctly on Kubernetes.

The idea: config out of the image

ConfigMap: non-sensitive settings

Secret: sensitive values

Injecting into a Pod: as env vars or as files

Important caveats about Secrets

Why it matters

Related questions