Configuration changes application behavior; credentials authorize access. They may reach a Pod through similar mechanisms, but they need different ownership, visibility, rotation, and evidence policies.
Quick answer
Use ConfigMaps for non-confidential configuration and Kubernetes Secrets only as a delivery object within a larger encryption, RBAC, audit, and rotation design. A Secret is not a vault and is not automatically encrypted at rest in every cluster. Prefer short-lived workload identity over static cloud keys when the platform supports it. Spring profiles select configuration groups; they are not a secret manager.
Learning objectives
- Choose between ConfigMap, Secret, mounted file, environment variable, and workload identity based on sensitivity and refresh behavior.
- Diagnose effective Spring configuration without printing credential values or confusing declared configuration with the winning property source.
Prerequisites
Review Spring Boot Configuration Properties, Profiles, and Secrets and Pods, Deployments, and Services. Continue through the course and topic.
Delivery and refresh boundaries
Environment variables are captured for the container process and do not update automatically when the source object changes. Projected volumes can update eventually, but the application must safely observe and apply changes. A rollout-on-change policy is often easier to reason about for immutable application configuration. Rotation must account for old and new credentials overlapping, connection pools, cached sessions, and rollback versions.
Workload identity lets a Pod obtain bounded credentials from an identity relationship instead of storing a long-lived provider key. The exact provider mechanism is outside this vendor-neutral course; the invariant is that identity, audience, subject, permissions, lifetime, and revocation remain explicit.
Production failure scenario
A database password rotates in the external owner and the Kubernetes Secret updates. Existing Pods keep the old environment variable and pooled connections. New Pods use the new value, while rollback Pods still require the old one. Operators log the decoded Secret during diagnosis, turning an availability issue into disclosure.
Stop exposing values. Determine which credential versions each workload and connection uses, apply the documented overlap or restart sequence, and verify authenticated business reads and writes. A Secret object update alone does not prove every process consumed it.
Common misconceptions
- Base64 encoding is not encryption.
- Kubernetes Secret access policy does not replace an external secret lifecycle.
- A ConfigMap or Secret update does not guarantee an application reload.
- A Spring profile name must not contain or imply the credential itself.
- Redacting logs after collection may not remove copies from every sink.
Decision checklist
- Classify every value by sensitivity, owner, lifetime, and refresh contract.
- Grant the Pod identity only the resources and actions it needs.
- Keep raw secrets out of images, manifests in Git, URLs, logs, traces, and metric labels.
- Plan rotation overlap, rollback compatibility, connection refresh, and revocation.
- Expose sanitized effective-source evidence rather than values.
- Verify final authenticated business behavior with the approved identity.
Continue with Kubernetes Probes and Graceful Shutdown for Spring Boot.
Related reading
- Spring Boot Configuration Properties, Profiles, and Secrets explains effective property precedence inside the process.
- Service Accounts Explained develops non-human identity and credential lifetime boundaries.
- Least Privilege Explained provides the authorization model for workload identities and secret access.
Official sources
- Kubernetes ConfigMaps, accessed August 18, 2026.
- Kubernetes Secrets, accessed August 18, 2026.
- Kubernetes ServiceAccounts, accessed August 18, 2026.
- Spring Boot externalized configuration, accessed August 18, 2026.