ConfigMaps vs Secrets in Kubernetes

A good container image is built once and runs in dev, staging, and prod without changes — which means its configuration can't be baked in. Kubernetes gives you two objects to inject config at runtime: ConfigMaps and Secrets. They work almost identically; the difference is what kind of data goes in each. And there's one caveat about Secrets that trips up nearly everyone.

The problem: config baked into the image

Hard-code a database URL or an API key into your image and you've made it unshippable — a new environment means a new build, and now secrets live in your image layers forever. Configuration has to come from outside the image, supplied at deploy time. That's exactly what these two objects do.

ConfigMap: non-sensitive configuration

A ConfigMap holds ordinary, non-secret settings — feature flags, log levels, service URLs, whole config files — as key/value pairs. You then feed it to a Pod either as environment variables or as mounted files:

env:
  - name: LOG_LEVEL
    valueFrom:
      configMapKeyRef: { name: app-config, key: log_level }

Change the ConfigMap to reconfigure the app without rebuilding the image. It's plain text, visible to anyone who can read the namespace — which is exactly why secrets don't belong here.

Secret: sensitive values

A Secret is structurally almost the same — key/value data injected as env vars or files — but it's meant for sensitive things: passwords, API keys, tokens, TLS certs. Kubernetes treats Secrets a little more carefully (they're not printed in describe output, can be scoped tightly with RBAC, and integrate with encryption features), and separating them from ConfigMaps lets you lock them down independently.

The caveat everyone must know

By default, a Secret's values are only base64-encoded, not encrypted. Base64 is encoding, not security — anyone can decode it in one command:

kubectl get secret db -o jsonpath='{.data.password}' | base64 -d   # plainly readable

So a Secret is not automatically safe. To make it actually protected you need to add: RBAC so only the right people/Pods can read it, encryption at rest for etcd (so it's not stored in plaintext on disk), and ideally an external secrets manager (Vault, cloud KMS) for anything serious. Treat "it's in a Secret" as "it's labelled sensitive," not "it's secured."

ConfigMap vs Secret is about intent and handling, not encryption. The value of a Secret is that it signals sensitive data and can be locked down separately — but the locking down is on you.

Why it matters

Externalising config is what makes the same image portable across environments and keeps credentials out of your image history and Git. Splitting sensitive from non-sensitive lets you apply tight access controls exactly where they're needed, and audit who can read what.

The mental model to keep

Both are "config injected from outside the image." ConfigMap = ordinary settings, in plain sight. Secret = sensitive data, flagged for special handling — but remember base64 ≠ encryption, so pair Secrets with RBAC and encryption at rest before you trust them with anything that would hurt to leak.

Frequently Asked Questions

What's the difference between a ConfigMap and a Secret?

ConfigMaps hold non-sensitive configuration; Secrets hold sensitive values like passwords and keys and can be locked down separately. Both inject into pods as env vars or mounted files.

Are Kubernetes Secrets encrypted?

Not by default — they're only base64-encoded, which anyone can decode. You need RBAC plus encryption at rest (or an external secrets manager) to actually protect them.

Can I store a password in a ConfigMap?

No — ConfigMaps are plain text visible to anyone with namespace access. Put it in a Secret, and secure that Secret properly.