Kubernetes ConfigMap, Secrets and Vault: Production Configuration and Secret Management

One image, many environments

I want:

one tested container image
   |
   +-> DEV configuration
   +-> QA configuration
   +-> UAT configuration
   `-> PROD configuration

I do not rebuild the code to change a timeout or endpoint.

ConfigMap

Non-sensitive values:

apiVersion: v1
kind: ConfigMap
metadata:
  name: booking-config
data:
  PAYMENT_TIMEOUT_MS: "2500"
  MAX_SEARCH_RESULTS: "100"
  ENABLE_NEW_SEARCH: "false"

Deployment:

envFrom:
  - configMapRef:
      name: booking-config

NestJS validation:

const schema = Joi.object({
  PAYMENT_TIMEOUT_MS:
    Joi.number()
      .integer()
      .min(100)
      .max(10000)
      .required(),

  MAX_SEARCH_RESULTS:
    Joi.number()
      .integer()
      .min(1)
      .max(500)
      .required(),
});

I prefer startup failure over accepting invalid production configuration.

Kubernetes Secret

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

Kubernetes Secret is a better boundary than ConfigMap, but base64 is not encryption.

I protect:

etcd encryption at rest
RBAC
namespace access
audit

Vault / cloud secret manager

For stronger lifecycle:

Pod identity
   |
Vault / AWS Secrets Manager / Azure Key Vault
   |
database credential
API token
certificate

Vault policy example:

path "secret/data/prod/booking/*" {
  capabilities = ["read"]
}

The booking workload should not read payment-service secrets.

Rotation

A secret system is valuable when rotation is operationally possible.

Questions:

Does app reread?
Does connection pool refresh?
Does pod require rollout?
What happens during overlap?

Database credential rotation can use two valid credentials during transition.

CSI / sidecar/agent approaches

Secrets can be:

• mounted as files;
• injected via sidecar/agent;
• fetched by SDK;
• synchronized into Kubernetes Secret.

Each has different rotation/failure semantics.

I choose based on platform standards.

What I never store

production password in Dockerfile
secret in Git
secret in ConfigMap
secret printed in CI log
full environment dump in application log

Production checklist

• ConfigMap only for non-secret data.
• Schema-validate configuration.
• Use workload identity.
• Least-privilege secret path.
• Encrypt etcd if native Secrets used.
• Audit access.
• Design rotation.
• Never log secrets.
• Separate environment scopes.
• Monitor expiry for certificates/keys.

FAQ

Is Kubernetes Secret encrypted?

Not automatically in every cluster. Configure encryption at rest and RBAC.

Vault vs AWS/Azure secret manager?

Cloud secret managers fit cloud-native platforms well. Vault is valuable for richer dynamic/multi-platform policies. I standardize rather than mixing tools without reason.

Environment variables or mounted files?

Both work. Mounted files can support some rotation patterns better; application behavior must be designed accordingly.

Related architecture guides

• Kubernetes Production Readiness

• CI/CD Promotion Pipeline

  Architect's final take

  Configuration and secrets are separate architecture concerns. I want application artifacts immutable, environment values explicit and sensitive material delivered through a controlled identity boundary.