ConfigMaps and Secrets

Prerequisites: completion of Deployments, Services, and Ingress, or comfort creating a Deployment and editing it with kubectl.

Version note: verified against kubernetes.io/docs/concepts/configuration docs, July 2026. The immutable: true field on both ConfigMap and Secret has been stable/GA since Kubernetes 1.21 and is unchanged in current releases (1.34–1.36).

Every environment your app runs in — your laptop, staging, production — needs slightly different configuration: a database hostname, a log level, a feature flag, an API key. Baking those into the container image means rebuilding the image for every environment, which defeats the point of building an image once and promoting it unchanged through your pipeline.

Kubernetes gives you two purpose-built objects for this: ConfigMap for non-sensitive configuration, and Secret for sensitive values like passwords and tokens. Neither encrypts data by default in etcd — Secrets are only base64-encoded, not encrypted, unless you separately enable encryption at rest — so a Secret's real value is the tighter RBAC and handling conventions Kubernetes applies to it, not built-in secrecy. For genuinely sensitive production credentials, most teams pair Secrets with an external secrets manager, which you'll see a pointer to at the end of this project.