Configuration
ConfigMaps and Secrets
ConfigMaps and Secrets decouple application configuration and sensitive data from the immutable container image. By injecting these resources at runtime, you maintain a single build artifact that behaves differently across development, testing, and production environments. This abstraction is essential for security, as it prevents hard-coding credentials and allows for dynamic updates without re-building the image.
Understanding ConfigMaps
A ConfigMap is a Kubernetes object designed to store non-sensitive, key-value configuration data. The core principle behind ConfigMaps is environment portability; your application code should remain agnostic of its deployment context. Instead of embedding a configuration file inside the container image, you define the desired settings as a Kubernetes resource. When the pod starts, the kubelet injects these values into the container environment or as files mounted in a specified directory. Because the application reads from these virtual locations, you can change the behavior of the application by updating the ConfigMap without ever modifying the underlying container image. This separation is vital for building a CI/CD pipeline where the exact same image passes through staging and production, differing only by the configuration injected at execution time.
# Example of a ConfigMap for application settings
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
DATABASE_HOST: "db-service.production.svc.cluster.local"
LOG_LEVEL: "INFO" # Adjust for debugging without code changesManaging Sensitive Data with Secrets
Secrets provide a dedicated mechanism for storing sensitive information, such as database credentials, API keys, or TLS certificates. Unlike ConfigMaps, which are stored as plain text within the etcd database, Secrets are intended to be base64-encoded to protect data from accidental exposure during casual inspection. It is important to note that base64 is an encoding, not encryption, meaning Secrets should be protected by Role-Based Access Control (RBAC) and integrated with external secret management systems in production environments. By separating sensitive data from regular configuration, you adhere to the principle of least privilege, ensuring that only the specific pods requiring access to the database credentials have the authorization to mount the corresponding Secret. This architectural design prevents credentials from being committed to source control and reduces the attack surface of your container infrastructure.
# Defining a Secret for sensitive database authentication
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
data:
username: YWRtaW4= # Base64 encoded 'admin'
password: c2VjcmV0cGFzc3dvcmQ= # Base64 encoded 'secretpassword'Injecting Data via Environment Variables
Environment variables are the most common way to pass configuration into an application process. When you map a key from a ConfigMap or Secret to an environment variable, the kubelet populates that variable within the container process memory space during startup. This approach is highly effective for simple key-value pairs like service endpoints or feature flags. Because the variable is injected directly into the process environment, the application code does not need to perform complex file system operations to read its configuration; it simply reads the standard process environment variables. However, caution is required when using this method for sensitive data, as these variables can sometimes be visible in process listings or log files if the application accidentally prints its full environment. Always use environment variables for lightweight settings and carefully validate the scope of access for the application's runtime process.
# Injecting ConfigMap and Secret as environment variables
spec:
containers:
- name: my-app
env:
- name: DB_HOST
valueFrom: {configMapKeyRef: {name: app-config, key: DATABASE_HOST}}
- name: DB_PASS
valueFrom: {secretKeyRef: {name: db-credentials, key: password}}Mounting Configurations as Volumes
While environment variables are convenient, they are limited by the fact that they cannot be updated while the container is running without a pod restart. Mounting ConfigMaps and Secrets as volumes solves this issue by creating files within the container's file system that represent the keys and values. This is particularly useful for configuration files like server settings or complex XML/YAML manifests. When the data in a mounted ConfigMap changes, Kubernetes automatically updates the file contents inside the container after a short delay, allowing the application to reload its configuration dynamically. By treating the configuration as a file volume, you provide the application with a familiar interface to read its settings, as most software is built to parse configuration files from disk rather than querying environment variables for large blocks of text or binary data.
# Mounting a ConfigMap as a file in a volume
spec:
volumes:
- name: config-volume
configMap: {name: app-config}
containers:
- name: my-app
volumeMounts:
- name: config-volume
mountPath: /etc/config # Files appear here: /etc/config/DATABASE_HOSTHandling Secrets Lifecycle and Updates
Managing the lifecycle of Secrets requires a disciplined approach to versioning and access control. Since Secrets are stored within the cluster's persistent storage, administrators must ensure that backups are encrypted and that API access is strictly limited to authorized users or service accounts. When a Secret is rotated, such as changing a database password, you must update the Secret object and potentially cycle the pods to ensure they pick up the new value. In complex systems, this is often handled by a sidecar container that monitors the Secret and triggers a reload signal or a controlled rolling update for the main application. By understanding the integration between the Kubernetes API and the container runtime, you can ensure that secret rotation happens securely without downtime, maintaining the integrity of your application secrets while adhering to robust operational security practices.
# Rolling update logic ensures pods restart with new secret values
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: my-app
env:
- name: API_KEY
valueFrom: {secretKeyRef: {name: db-credentials, key: password}}Key points
- ConfigMaps provide a way to store non-sensitive configuration data for injection into containers.
- Secrets are specifically designed to handle sensitive information like passwords and tokens securely.
- Decoupling configuration from container images enables the promotion of identical images across different environments.
- Environment variables offer a simple way to inject data, but are best suited for non-sensitive, static values.
- Volume mounting allows for dynamic updates of configuration files without requiring a pod restart in many scenarios.
- Secrets should be protected via RBAC to ensure that only authorized pods can access sensitive data.
- Base64 encoding for Secrets serves as a protection against accidental visibility rather than a security encryption layer.
- Proper lifecycle management of secrets includes secure rotation processes to minimize risk in the event of credential leakage.
Common mistakes
- Mistake: Storing sensitive data like passwords or API keys in a ConfigMap. Why it's wrong: ConfigMaps are stored in plain text in etcd and are not encrypted by default. Fix: Use Kubernetes Secrets, which are designed for sensitive data and support encryption at rest.
- Mistake: Hardcoding secrets into Dockerfiles. Why it's wrong: Anyone with access to the container image can extract the secret layer from the image history. Fix: Inject secrets at runtime using Kubernetes Secret volumes or environment variables.
- Mistake: Assuming ConfigMap updates immediately propagate to all pods. Why it's wrong: When mounted as a volume, updates occur eventually, but environment variables do not refresh without a pod restart. Fix: Use rolling updates or signal the application to reload configuration.
- Mistake: Not setting the 'immutable' flag on static configuration. Why it's wrong: Accidental updates to configuration can lead to inconsistent state across a cluster. Fix: Set 'immutable: true' in the ConfigMap or Secret spec to prevent changes and improve performance.
- Mistake: Using Secrets in environment variables for highly sensitive data. Why it's wrong: Environment variables can be leaked through logs, crash reports, or child processes. Fix: Mount the Secret as a file within a volume for improved security.
Interview questions
What is the primary difference between a ConfigMap and a Secret in Kubernetes?
A ConfigMap is designed to store non-sensitive configuration data such as environment variables, command-line arguments, or configuration files, allowing you to decouple environment-specific settings from your container images. A Secret, conversely, is explicitly designed to store sensitive information like passwords, OAuth tokens, or SSH keys. While ConfigMaps store data in plain text, Secrets provide an additional layer of security by ensuring that sensitive data is base64 encoded and, in modern clusters, encrypted at rest within the etcd database, which is critical for compliance and security best practices.
How do you inject ConfigMap data into a Kubernetes Pod, and what are the two common methods?
There are two primary ways to inject ConfigMap data: as environment variables or as mounted volumes. Using environment variables is ideal for simple configuration settings; you reference the ConfigMap key in your pod manifest under the 'envFrom' or 'valueFrom' fields. Alternatively, mounting a ConfigMap as a volume is preferred for file-based configurations. By defining a volume in the pod specification, the ConfigMap data appears as files within a directory in your container, which is particularly useful for mounting entire configuration files like application.properties or nginx.conf that the container needs at runtime.
What happens if a Pod attempts to mount a Secret or ConfigMap that does not exist?
If a Pod references a non-existent ConfigMap or Secret, the Kubernetes scheduler will successfully schedule the Pod, but it will fail to start. The Pod will enter a 'CreateContainerConfigError' or 'ContainerCreating' state, and the events will log an error stating that the volume or environment variable reference could not be found. To mitigate this, you can mark a Secret or ConfigMap as 'optional: true' in your pod definition, which allows the Pod to start even if the resource is missing, preventing unnecessary downtime during deployment updates.
Compare the security implications of using environment variables versus volume mounts for storing Secrets in Kubernetes.
While both methods are common, volume mounts are generally considered more secure than environment variables for Secrets. When using environment variables, sensitive data can be inadvertently exposed through logs, process dumps, or child processes, as environment variables are inherited by default. In contrast, when you mount a Secret as a volume, the sensitive information exists only within a specific file on the container's file system, which can be managed with specific file permissions and is not exposed in the process environment, thereby reducing the attack surface significantly.
How can you update configuration data without requiring a restart of the application container?
When you mount a ConfigMap or Secret as a volume, Kubernetes automatically updates the files inside the pod when the source object changes, although this process can be delayed by the Kubelet sync period. Applications that watch for file system changes can detect these updates and hot-reload their configuration without a container restart. However, if you inject data via environment variables, the variables are static; they are only set when the container starts. Therefore, to update environment-based configurations, you must perform a rolling restart of the Deployment to recreate the Pods and pick up the new values.
Explain the concept of 'Immutable Secrets and ConfigMaps' and why you would use this feature in a production environment.
The 'immutable' field, which can be set to true in a ConfigMap or Secret, prevents any updates to the resource data once it has been created. In production, this is used to ensure configuration consistency and integrity. If you attempt to update an immutable resource, the API server will reject the change, forcing you to create a new resource version instead. This prevents 'configuration drift,' where running pods might have inconsistent settings, and ensures that you can reliably rollback or audit changes, as every configuration update is tracked via unique resource names and versioned manifests.
Check yourself
1. If you need to update a configuration file managed by a ConfigMap mounted as a volume, what is the best way to ensure the application picks up the change?
- A.Delete and recreate the deployment
- B.Wait for the kubelet to sync the volume and ensure the application watches the file for changes
- C.Restart the Kubernetes API server
- D.Update the ConfigMap and manually execute a kill command on the process inside the container
Show answer
B. Wait for the kubelet to sync the volume and ensure the application watches the file for changes
Mounting as a volume allows for atomic updates via symbolic link swapping. If the application is designed to watch the file, it will refresh without a restart. Option 0 and 3 are invasive, and option 2 is not necessary for configuration sync.
2. Why is a Kubernetes Secret not considered a 'vault' or 'encryption-at-rest' solution by default?
- A.Secrets are only stored in memory
- B.Secrets are base64 encoded by default, not encrypted
- C.Secrets are only available to the namespace creator
- D.Secrets do not support RBAC policies
Show answer
B. Secrets are base64 encoded by default, not encrypted
Kubernetes Secrets are base64 encoded, which is encoding, not encryption. Anyone with etcd access can decode them. Option 0 is false, option 2 is false as they can be shared across namespaces if needed, and option 3 is false because RBAC is the primary way to secure them.
3. What happens to a pod if you update a ConfigMap that is being consumed strictly as an environment variable?
- A.The environment variable in the pod updates automatically after a short delay
- B.The pod will automatically restart to pick up the new value
- C.The pod will continue to use the original value until the pod is recreated
- D.The container process will crash due to a mismatch in configuration
Show answer
C. The pod will continue to use the original value until the pod is recreated
Environment variables are injected at pod creation time. Changes to the source ConfigMap do not reflect in existing pods. Option 0 is false, option 1 does not happen automatically, and option 3 is incorrect as the process has no way of knowing the config changed.
4. Which of the following is the most secure way to consume a Secret containing a TLS private key in a pod?
- A.Injecting it as an environment variable
- B.Mounting the secret as a volume at a specific path
- C.Passing it as an argument in the command list
- D.Storing it directly in the Dockerfile as a build argument
Show answer
B. Mounting the secret as a volume at a specific path
Mounting as a volume keeps sensitive files off the process environment and logs. Environment variables (0) and command arguments (2) can be logged or inspected by unauthorized users. Option 3 is a major security vulnerability.
5. When defining a ConfigMap, what is the significance of the 'data' versus the 'binaryData' field?
- A.data is for JSON, binaryData is for YAML
- B.data is for UTF-8 encoded strings, binaryData is for base64 encoded binary blobs
- C.binaryData allows for larger files than the data field
- D.data is encrypted, while binaryData is not
Show answer
B. data is for UTF-8 encoded strings, binaryData is for base64 encoded binary blobs
ConfigMaps use 'data' for standard string-based key-value pairs, while 'binaryData' is intended for non-textual data like images or certificates. The other options misrepresent the structural intent of the fields.