ConfigMaps and Secrets

In Module 4, you built a Deployment that ran a specific container image with a specific environment. What happens when your API key expires and you need to update it? Or when you move from development to production and need different database URLs? Rebuilding your entire container image just to change a configuration value is wasteful and error-prone.

ConfigMaps and Secrets solve this by decoupling configuration from your container image. You store configuration in Kubernetes objects, inject them into your Pods, and change configuration without rebuilding anything. ConfigMaps handle non-sensitive data (URLs, feature flags). Secrets handle sensitive data (API keys, database credentials). Both use the same injection patterns—the difference is in how they're stored and accessed.

---

The Problem: Configuration Baked Into Images

Imagine your AI agent needs an API key to call an external service. Your Dockerfile hardcodes it:

Problems with this approach:

Kubernetes ConfigMaps and Secrets invert this model: the image contains no configuration. Kubernetes injects configuration at runtime.

---

ConfigMaps: Non-Sensitive Configuration

A ConfigMap is a Kubernetes object that stores key-value pairs or file content. It's not encrypted—use it for non-sensitive configuration like URLs, feature flags, and log levels.

Creating a ConfigMap with kubectl

The fastest way to create a ConfigMap is with the kubectl command:

Output:

This creates a ConfigMap named app-config with three key-value pairs. Let's examine it:

Output:

Notice: ConfigMaps are plain text. No encryption. They're for non-sensitive data only.

Creating a ConfigMap with YAML Manifest

For reproducibility, define ConfigMaps in YAML:

Apply it:

Output:

The YAML approach is preferred in production because it's version-controlled and reproducible.

---

Secrets: Sensitive Data

Secrets work like ConfigMaps but are designed for sensitive data: API keys, database passwords, tokens. The key difference: Kubernetes stores Secrets separately from regular data, and some storage backends can encrypt them (though by default, Kubernetes base64-encodes Secrets, which is NOT encryption).

Creating a Secret with kubectl

Output:

Let's examine it:

Output:

Notice the data field contains base64-encoded values. Let's decode one:

Output:

Creating a Secret with YAML Manifest

For production, define Secrets in YAML with base64-encoded values:

Or let Kubernetes do the encoding using stringData:

When using stringData, Kubernetes automatically base64-encodes the values when storing them. Apply it:

Output:

---

Injecting Configuration as Environment Variables

Once you have a ConfigMap or Secret, inject it into a Pod as environment variables.

Environment Variable Injection from ConfigMap

Create a Deployment that injects the app-config ConfigMap:

Implementation Breakdown:

Apply this Deployment:

Output:

Verify the Pods received the configuration:

Output:

Check the environment inside a Pod:

Output:

Verify the database password is also present:

Output:

---

Mounting Configuration as Files

Sometimes your application expects configuration in files, not environment variables. Use volume mounts to inject ConfigMaps and Secrets as files.

Mounting a ConfigMap as a Volume

Create a ConfigMap with file-like data:

Now mount this ConfigMap as files in a Deployment:

Apply this Deployment:

Output:

Verify the files exist inside the Pod:

Output:

Read the configuration file:

Output:

Mounting a Secret as a Volume

Mounting Secrets as files works identical to ConfigMaps:

Apply:

Output:

Verify the secret files exist:

Output:

---

Important: Base64 Encoding Is NOT Encryption

This is critical for security understanding: Kubernetes Secrets are base64-encoded, but base64 is encoding, not encryption. Anyone with access to the Secret object can decode it immediately.

Data Example:

This password is trivially decodable:

Output:

Security Best Practices:

---

Practice Exercises

Exercise 1: Create a ConfigMap and Inject It

Create a ConfigMap named agent-config with these keys:

Then create a Pod that injects this ConfigMap as environment variables. Verify the Pod receives the configuration.

Solution:

Create a Pod manifest:

Apply and verify:

Output:

---

Exercise 2: Create a Secret and Mount as Files

Create a Secret named db-secrets with:

Mount this Secret into a Pod at /etc/db-secrets/ and verify you can read the files.

Solution:

Create a Pod manifest:

Apply and verify:

Output:

---

Exercise 3: Update a ConfigMap and Redeploy

Create a Deployment that uses a ConfigMap. Update the ConfigMap and observe whether the Pods automatically receive the new configuration.

Solution:

Create initial ConfigMap:

Create Deployment:

Apply:

Output:

Now update the ConfigMap:

Important Discovery: The existing Pod still sees the old value. Kubernetes doesn't automatically reload ConfigMap changes into running Pods. To apply the new configuration, you must restart the Deployment:

Output:

This teaches an important lesson: ConfigMaps aren't "live"—they're read when the Pod starts. To update configuration, you redeploy the Pods.

---

Try With AI

In this section, you'll collaborate with AI to generate ConfigMaps and Secrets for your Module 6 agent.

Step 1: Planning Your Configuration

Your Module 6 FastAPI agent needs external configuration. You'll ask AI to help you design which values belong in ConfigMaps and which in Secrets.

Ask AI:

Step 2: Critical Evaluation

Review the AI response. Ask yourself:

• Did it correctly classify sensitive vs non-sensitive data?
• Did it create separate ConfigMap and Secret objects?
• Does the YAML follow Kubernetes conventions (metadata, kind, apiVersion)?
• Are the data keys clearly named?

Step 3: Refinement

Based on your evaluation, tell AI:

Step 4: Validation

AI generates an updated Deployment. Review it:

• Does the ConfigMap injection use envFrom.configMapRef?
• Does the Secret injection use env[].valueFrom.secretKeyRef?
• Are all the configuration keys properly referenced?

Step 5: Implementation Check

Ask AI:

This exercises your ability to prompt AI for iterative refinement of configuration manifests—a skill you'll use frequently when deploying to Kubernetes.

---

Reflect on Your Skill

You built a kubernetes-deployment skill in Chapter 1. Test and improve it based on what you learned.

Test Your Skill

Identify Gaps

Ask yourself:

• Did my skill include ConfigMap creation from literals and YAML manifests?
• Did it explain Secret creation and the base64 encoding (not encryption) caveat?
• Did it cover both environment variable injection and volume mount patterns?
• Did it include security warnings about Secret management in production?

Improve Your Skill

If you found gaps:

---

Source: https://www.muhammadusmanakbar.com/book