Use ConfigMaps and Secrets to configure applications
5 minutes
5 Questions
In the context of the CKA exam and Workloads & Scheduling, decoupling configuration from container images is a core best practice. ConfigMaps and Secrets are the Kubernetes primitives used to inject this configuration data into Pods, allowing the same container image to be portable across different…In the context of the CKA exam and Workloads & Scheduling, decoupling configuration from container images is a core best practice. ConfigMaps and Secrets are the Kubernetes primitives used to inject this configuration data into Pods, allowing the same container image to be portable across different environments (Dev, QA, Prod).
ConfigMaps are designed for non-sensitive data, such as config files (e.g., nginx.conf), command-line arguments, or standard environment variables. You can inject ConfigMap data into containers in three primary ways: as individual environment variables using `valueFrom`, as a set of environment variables using `envFrom`, or as files mounted to a specific path via a Volume. This flexibility allows applications to read configuration at startup or watch for file changes.
Secrets handle sensitive data like passwords, OAuth tokens, and SSH keys. While usage syntax mimics ConfigMaps, Secrets are base64-encoded and can be encrypted at rest within etcd. Like ConfigMaps, they can be exposed via environment variables or volumes. Security best practices suggest using Volume mounts for Secrets, as this stores data in an in-memory tmpfs rather than writing to disk, minimizing leakage risks.
For the CKA, you must master the imperative creation of these objects (e.g., `kubectl create configmap --from-literal`) and their integration into Pod manifests. A crucial distinction for scheduling is the update behavior: updates to ConfigMaps/Secrets mounted as Volumes are reflected automatically in the Pod (eventually), whereas Environment Variables are injected only at startup, requiring a Pod restart to apply changes.
Use ConfigMaps and Secrets to Configure Applications
Why is it Important? Hardcoding configuration data (like database URLs) or sensitive credentials (like passwords) directly into container images violates the 12-Factor App principles. It makes images heavy, insecure, and rigid. Kubernetes solves this by separating configuration code from application code using ConfigMaps and Secrets. This decoupling allows you to keep container images immutable and portable across different environments (Dev, Test, Prod) while injecting the specific configuration required for each environment at runtime.
What are they? ConfigMaps: Kubernetes API objects used to store non-confidential data in key-value pairs. They allow you to bind configuration artifacts to your Pods' containers and system components at runtime. Secrets: Similar to ConfigMaps but specifically intended to hold confidential data such as passwords, OAuth tokens, and SSH keys. While ConfigMaps store data in plain text, Secrets store data encoded in base64 (Note: Encoding is not encryption; access controls are vital).
How it Works Both resources follow a similar lifecycle: 1. Creation: You create the object via YAML manifests or imperative commands (e.g., kubectl create secret generic...). 2. Storage: The data is stored in etcd (Secrets can be encrypted at rest). 3. Consumption: Pods consume these resources in one of three ways: - As individual environment variables. - As a set of environment variables (using envFrom). - Mounted as a Volume, where keys become filenames and values become file content.
How to Answer Questions in the Exam CKA questions on this topic usually require a three-step process: 1. Create: Generate the ConfigMap or Secret based on given literals or an existing file. 2. Modify Pod/Deployment: Edit an existing Pod or Deployment YAML to include the reference. 3. Verify: Exec into the Pod to ensure variables are set or files exist.
Exam Tips: Answering Questions on Use ConfigMaps and Secrets 1. Speed with Imperative Commands: Avoid writing YAML from scratch for creation. Use: kubectl create configmap my-config --from-literal=key1=value1 --from-file=path/to/file kubectl create secret generic my-secret --from-literal=pass=12345
2. Environment Variables vs. Volumes: Read the requirement carefully. If asked to 'configure the application to use the variable APP_COLOR', use the env section in the Pod spec. If asked to 'provide the config file at /etc/config', use volumes and volumeMounts.
3. Decoding Secrets: If you need to check the value of an existing secret, use: kubectl get secret my-secret -o jsonpath='{.data.key}' | base64 --decode
4. Handling Updates: Remember that environment variables are injected at startup; updating a ConfigMap will not update the environment variable in a running Pod (restart required). However, data mounted as Volumes will eventually update automatically without a restart.
5. Syntax Shortcut: When injecting all key-values as environment variables, use envFrom instead of listing every key individually.