← CKAD: Kubernetes applications in production
05 / 7 · 24 MIN

Configuration, secrets, and identity

Coordinate configuration delivery with how the process consumes it.

Concept and mechanism

ConfigMaps store nonconfidential configuration; Secrets represent sensitive data requiring protection and controlled access. Base64 is reversible encoding, not encryption. Never assume the Secret kind protects copies in logs or Git. Environment variables are established when the container starts. Updating their source does not rewrite existing process environments. Projected volumes use another update mechanism, and subPath mounts do not automatically receive Secret changes. Even with an updated file, the application may need to reread its content.

Guided application

Rotation should connect new credential creation, distribution, consumption, and old credential revocation. If policy allows overlap, a controlled rollout can validate authentication before revocation. Identify batch consumers too. For Kubernetes API access, a ServiceAccount identifies the workload and RBAC authorizes operations in the required scope. A valid token does not grant every verb. If the workload needs no token, consider disabling automatic mounting and check integrations that might depend on it. Retain evidence without recording secret values.

IN PRACTICE

An API receives its password through secretKeyRef. Update the source, replace Pods under control, confirm new connections, then retire the old credential within the agreed window.

Common pitfalls

Confusing base64 with confidentiality; rotating tokens to fix RBAC; revoking without confirming new-credential consumption.

Related topics: Resources, security, and extensions · Services, DNS, and isolation

Take this idea with you

A change finishes only when consumers use the intended configuration.

Create account

Reference: Secrets · CKAD Kubernetes v1.35