How do I manage secrets and config in Kubernetes?

A good Kubernetes approach is to treat configuration and secrets differently:

• Config = non-sensitive settings like feature flags, URLs, log levels
• Secrets = passwords, API keys, certificates, tokens

1) Use ConfigMaps for non-sensitive config

Store application settings in a ConfigMap, then inject them as environment variables or mounted files.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: "info"
  APP_MODE: "production"

Use it in a Pod:

envFrom:
  - configMapRef:
      name: app-config

Or mount as files:

volumes:
  - name: config
    configMap:
      name: app-config
volumeMounts:
  - name: config
    mountPath: /etc/config

2) Use Secrets for sensitive values

Store sensitive data in a Secret.

Example:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  username: cG9zdGdyZXM=
  password: c3VwZXJzZWNyZXQ=

Note: data values must be base64-encoded.

Use it in a Pod:

envFrom:
  - secretRef:
      name: db-secret

Or mount as files:

volumes:
  - name: secret-vol
    secret:
      secretName: db-secret
volumeMounts:
  - name: secret-vol
    mountPath: /etc/secret
    readOnly: true

3) Prefer external secret management for real production

Kubernetes Secrets are better than plaintext files, but by default they are only base64-encoded, not strongly protected unless you enable encryption at rest and proper RBAC.

For production, consider:

• External Secrets Operator
• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager

These tools let Kubernetes fetch secrets from a trusted external store.

4) Never put secrets directly in Git

Avoid committing secrets into:

• manifests
• Helm values files
• Docker images
• environment variables in CI logs

Use:

• sealed secrets
• SOPS + age/GPG
• external secret operators
• CI/CD secret stores

5) Use RBAC and encryption

If you do use Kubernetes Secrets:

• enable RBAC to limit who can read them
• enable encryption at rest for etcd
• restrict access to namespaces
• audit secret access

6) Choose env vars vs mounted files

Environment variables

• easy to use
• good for simple config
• less ideal for large or frequently rotated secrets

Mounted files

• better for certs, keys, and larger config
• can be updated more cleanly in some cases

7) Rotate secrets

Plan for rotation:

• make apps reload credentials safely
• use short-lived credentials where possible
• use secret managers that support automatic rotation

8) Useful best practices

• separate config by environment: dev/stage/prod
• keep secrets and config in separate resources
• use immutable secrets/config when appropriate
• validate config on startup
• avoid logging secret values

Simple rule of thumb

• ConfigMap for non-sensitive config
• Secret for sensitive data
• External secret manager for production-grade security

If you want, I can show you:

1. a full example Deployment using both ConfigMap and Secret, or
2. a recommended setup with External Secrets + Vault/AWS Secrets Manager.