4.03 Configure Env Variables,ConfigMaps & Secrets in Applications

Kubernetes lets you pass configuration into containers using:

Environment variables
ConfigMaps
Secrets

This keeps configuration separate from container images and makes apps easier to manage and update.

🎯 Why Use Environment Configuration

Applications often need runtime configuration such as:

App mode (dev / prod)
Feature flags
Colors / themes
DB hostnames
Ports
External service URLs

Hard-coding these inside images is bad practice.

Success

Kubernetes supports external configuration using env, ConfigMaps, and Secrets.

🧪 Basic Environment Variable in a Pod

Equivalent Docker command:

docker run -e APP_COLOR=pink simple-webapp-color

Kubernetes Pod YAML:

apiVersion: v1
kind: Pod
metadata:
  name: simple-webapp-color
spec:
  containers:
    - name: app
      image: simple-webapp-color
      ports:
        - containerPort: 8080
      env:
        - name: APP_COLOR
          value: pink

Note

env is a list — each variable is a separate item.

🧩 Environment Value Sources (3 Ways)

Kubernetes supports three env value types:

Plain key/value
ConfigMap
Secret

Plain Key ValueFrom ConfigMapFrom Secret

env:
  - name: APP_COLOR
    value: pink

env:
  - name: APP_COLOR
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_COLOR

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

🗂️ What Is a ConfigMap

A ConfigMap stores configuration as key–value pairs in Kubernetes.

Benefits:

Central config storage
Reusable across Pods
No image rebuild required
Easy updates

Abstract

ConfigMap = configuration outside the container image.

✍️ Create ConfigMap — Imperative Method

From Literal Values

kubectl create configmap app-config \
  --from-literal=APP_COLOR=blue \
  --from-literal=APP_MODE=prod

From File

kubectl create configmap app-config \
  --from-file=app.properties

📄 Create ConfigMap — Declarative Method

ConfigMap YAML:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_COLOR: blue
  APP_MODE: prod

Create:

kubectl apply -f configmap.yaml

🔍 View ConfigMaps

kubectl get configmaps
kubectl describe configmap app-config

🚀 Inject ConfigMap into Pod — All Keys

Load all keys as environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
    - name: app
      image: simple-webapp-color
      envFrom:
        - configMapRef:
            name: app-config

Result inside container:

APP_COLOR=blue
APP_MODE=prod

Tip

envFrom loads all keys from the ConfigMap.

🎯 Inject Single ConfigMap Key

env:
  - name: APP_COLOR
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: APP_COLOR

Note

Use this when you only need specific keys.

💾 Inject ConfigMap as Volume

ConfigMap can also be mounted as files.

volumes:
  - name: config-vol
    configMap:
      name: app-config

containers:
  - name: app
    image: simple-webapp-color
    volumeMounts:
      - name: config-vol
        mountPath: /etc/config

Result inside container:

/etc/config/APP_COLOR
/etc/config/APP_MODE

⚠️ When to Use Secrets Instead

Use Secrets instead of ConfigMaps for:

Passwords
Tokens
Keys
Certificates

Warning

ConfigMaps are NOT encrypted — Secrets are.

❓ Exam-Style Checks

Question

Where is ConfigMap data stored?

In Kubernetes API (etcd).

Question

Does ConfigMap require Pod restart after change?

Usually yes (unless app reloads dynamically).

Question

Can ConfigMap be used as files?

Yes — via volume mount.

✅ Quick Summary

Summary

Use env for simple variables
Use ConfigMaps for shared configuration
Create via kubectl or YAML
Inject using env, envFrom, or volumes
envFrom loads all keys
configMapKeyRef loads one key
Use Secrets for sensitive data

Kubernetes Secrets

Kubernetes Secrets are used to store and manage sensitive data such as:

Passwords
API keys
Tokens
Database credentials

Secrets are similar to ConfigMaps — but meant for confidential values.

🎯 Why Secrets Are Needed

Hard-coding credentials inside application code or Pod YAML is unsafe.

Example (❌ bad practice):

mysql.connect(
  host="mysql",
  user="root",
  password="passwd"
)

Instead — move sensitive values into Kubernetes Secrets and inject them securely.

Warning

Do NOT store passwords in Pod specs or container images.

🧠 Secrets vs ConfigMaps

Feature	ConfigMap	Secret
Purpose	Non-sensitive config	Sensitive data
Storage	Plain text	Base64 encoded
Use case	App settings	Credentials, keys

Note

Secrets are base64-encoded — not encrypted by default.

🔐 Secret Workflow (2 Steps)

Step 1 → Create Secret
Step 2 → Inject into Pod

Secrets can be injected as:

Environment variables
Single env values
Mounted volume files

⚙️ Create Secrets — Imperative Method

From Literal Values

kubectl create secret generic app-secret \
  --from-literal=DB_Host=mysql \
  --from-literal=DB_User=root \
  --from-literal=DB_Password=passwd

From File

kubectl create secret generic app-secret \
  --from-file=secret.properties

Tip

Good when many secret keys exist.

📦 Create Secrets — Declarative Method

Secrets YAML requires base64 encoded values.

Encode Values

echo -n 'mysql' | base64
echo -n 'root' | base64
echo -n 'passwd' | base64

Secret YAML

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_Host: bXlzcWw=
  DB_User: cm9vdA==
  DB_Password: cGFzc3dk

Apply:

kubectl apply -f secret.yaml

Success

Declarative method is preferred for GitOps.

🔍 View Secrets

List

kubectl get secrets

Describe (values hidden)

kubectl describe secret app-secret

View YAML (encoded values visible)

kubectl get secret app-secret -o yaml

🔓 Decode Secret Value

echo 'bXlzcWw=' | base64 --decode

Note

Base64 encoding is reversible — enable etcd encryption for real security.

🚀 Inject Secrets into Pods — All as ENV

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
spec:
  containers:
    - name: app
      image: myapp
      envFrom:
        - secretRef:
            name: app-secret

Result inside container:

DB_Host
DB_User
DB_Password

🎯 Inject Single Secret Key

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secret
        key: DB_Password

Tip

Use this when you only need one value.

📁 Mount Secret as Volume

Each secret key becomes a file.

spec:
  containers:
    - name: app
      image: myapp
      volumeMounts:
        - name: secret-vol
          mountPath: /opt/secrets

  volumes:
    - name: secret-vol
      secret:
        secretName: app-secret

Inside container:

ls /opt/secrets
cat /opt/secrets/DB_Password

🧭 Secret Injection Diagram

Secret Object
   │
   ├── envFrom → all keys → env vars
   │
   ├── secretKeyRef → single key → env var
   │
   └── volume mount → keys → files

⚠️ Important Security Notes

Warning

Base64 is encoding — not encryption.

Warning

Enable etcd encryption for production clusters.

Tip

Use RBAC to restrict secret access.

Tip

Avoid committing Secret YAML with real values to Git.

🧪 Exam-Style Checks

Question

Are Secrets encrypted by default?

No — only base64 encoded.

Question

How many steps to use Secrets?

Create → Inject.

Question

Can Secrets be used as files?

Yes — via volume mount.

Question

Which field injects all keys as env vars?

envFrom + secretRef

✅ Quick Summary

Summary

Secrets store sensitive data
Similar to ConfigMaps but for credentials
Values stored base64 encoded
Create via imperative or YAML
Inject using envFrom, secretKeyRef, or volumes
Describe hides values
YAML shows encoded values
Use RBAC + etcd encryption in production