Configuration & Secrets

ConfigMaps

ConfigMaps store non-sensitive configuration data as key-value pairs. Mount them as files in pods or inject as environment variables. Updating a ConfigMap does not automatically restart pods — use a rollout trigger or operator.

Separate configuration from code. The same container image runs in dev, staging, and production with different ConfigMaps.

• All ConfigMap values must be strings — quote numbers
• Mount as files for apps that read config from disk
• Use envFrom for bulk environment variable injection

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: info
  MAX_CONNECTIONS: "100"
  app.properties: |
    server.port=3000
    server.host=0.0.0.0

Secrets

Secrets store sensitive data — passwords, tokens, TLS certificates. They are base64-encoded (not encrypted by default). Enable encryption at rest with a KMS provider for production.

Mount secrets as files (preferred) or environment variables. File mounts support automatic updates. Never log secret values or commit them to git.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: dXNlcg==     # base64 encoded
  password: cGFzc3dvcmQ=

# Better: use external secret management
# External Secrets Operator syncs from Vault/AWS SM

Injecting Configuration

Reference ConfigMaps and Secrets in pod specs via env (individual keys), envFrom (all keys), volumeMounts (as files), or projected volumes (combining sources).

File mounts create a directory with one file per key. Environment variables are set at pod creation and do not update if the ConfigMap changes.

spec:
  containers:
    - name: app
      envFrom:
        - configMapRef:
            name: app-config
      env:
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: password
      volumeMounts:
        - name: config
          mountPath: /etc/config
          readOnly: true
  volumes:
    - name: config
      configMap:
        name: app-config

External Secret Management

For production, use External Secrets Operator or Secrets Store CSI Driver to sync secrets from Vault, AWS Secrets Manager, or Azure Key Vault. Secrets never live in etcd or git.

The operator watches external stores and creates Kubernetes Secrets automatically. Rotation in the external store propagates to pods on next restart.

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: db-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: password
      remoteRef:
        key: prod/database
        property: password

Configuration Best Practices

Use separate ConfigMaps per application and environment. Version configuration changes in git alongside application code. Validate configuration at startup — fail fast on missing or invalid config.

Implement a configuration reload mechanism for non-sensitive settings. Sensitive settings should require pod restart to pick up changes.

# Directory structure
# config/
#   base/
#     app-config.yaml
#   overlays/
#     staging/
#       kustomization.yaml
#     production/
#       kustomization.yaml