22 Kubernetes Configuration and Secrets
Kubernetes Configuration and Secrets manage containerized applications' settings and sensitive data securely across cluster environments.
Kubernetes Configuration and Secrets is the mechanism by which Kubernetes separates application configuration data and sensitive credentials from container images, allowing the same image to be reused across environments and allowing configuration to be updated without rebuilding or redeploying the application code itself.
Why Externalize Configuration
Portability Across Environments
Baking configuration values directly into a container image ties that image to a specific environment, requiring a new image build for every configuration change. Externalizing configuration allows the same image to run in development, staging, and production, differing only in the configuration supplied at deployment time.
Separating Code from Configuration
This separation reflects a broader software engineering principle: application logic should not need to change when only its configuration changes, and Kubernetes provides first-class objects to enforce that separation.
ConfigMaps
Storing Non-Sensitive Data
A ConfigMap holds configuration data as key-value pairs, intended for non-sensitive values such as feature flags, connection endpoints that are not secrets themselves, or entire configuration files consumed by an application.
Consuming ConfigMaps
A ConfigMap's data can be injected into a container as environment variables, or mounted as files into the container's filesystem, giving applications flexibility in how they read the values depending on whether they expect environment-based or file-based configuration.
Secrets
Storing Sensitive Data
A Secret is structurally similar to a ConfigMap but is intended for sensitive values such as passwords, API tokens, and TLS certificates, and receives handling considerations, such as being held in memory rather than written to disk on nodes where possible, that ConfigMaps do not.
Encoding Is Not Encryption
Secret values are stored base64-encoded by default, which obscures but does not encrypt the data; meaningful protection requires enabling encryption at rest for the cluster's data store and applying strict access controls to who can read Secret objects.
Injecting Configuration into Pods
Environment Variables
Both ConfigMap and Secret values can be exposed to a container as individual environment variables, or all keys within them can be bulk-injected as a set of environment variables at once.
Volume Mounts
Alternatively, ConfigMaps and Secrets can be mounted as files within a container's filesystem, which is particularly useful for applications that expect to read configuration from a file rather than from environment variables, and allows updated values to be reflected without restarting the container in many cases.
Access Control for Secrets
Role-Based Access Control
Because Secrets often contain highly sensitive material, access to read or modify them is typically restricted through Role-Based Access Control, limiting which users or service accounts can retrieve their contents.
External Secret Management Integration
Many clusters integrate with external secret management systems, synchronizing sensitive values from a dedicated vault into Kubernetes Secrets, reducing the need to store the most sensitive material directly and persistently within the cluster's own data store.
Configuration Update Behavior
Reflected Changes
Updates to a ConfigMap or Secret referenced by a mounted volume are eventually reflected inside running containers without requiring a restart, though environment variables sourced from them are only set at container startup and do not update automatically.