KCNA — ConfigMaps & Secrets
ConfigMaps & Secrets
ConfigMaps and Secrets let you separate configuration from application code. This follows the Twelve-Factor App principle of externalizing configuration.
ConfigMaps
What Is a ConfigMap?
A ConfigMap stores non-sensitive configuration data as key-value pairs.
| Aspect | Details |
|---|---|
| Purpose | Store configuration data separately from pod specs |
| Data type | Non-sensitive — environment variables, config files, command-line arguments |
| Format | Key-value pairs (string data) |
| Size limit | 1 MiB per ConfigMap |
How to Use ConfigMaps
ConfigMaps can be consumed by pods in three ways:
| Method | How It Works |
|---|---|
| Environment variables | Each key becomes an env var in the container |
| Volume mount | Each key becomes a file in a mounted directory |
| Command-line arguments | Values can be referenced in container commands |
Example
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
DATABASE_HOST: "db.example.com"
DATABASE_PORT: "5432"
LOG_LEVEL: "info"
Secrets
What Is a Secret?
A Secret stores sensitive data like passwords, tokens, and certificates.
| Aspect | Details |
|---|---|
| Purpose | Store sensitive configuration data separately from pod specs |
| Data type | Sensitive — passwords, API keys, TLS certificates, tokens |
| Encoding | Values are Base64-encoded (NOT encrypted by default!) |
| Size limit | 1 MiB per Secret |
Types of Secrets
| Type | Use Case |
|---|---|
| Opaque (default) | Generic key-value pairs (passwords, tokens) |
| kubernetes.io/tls | TLS certificates and private keys |
| kubernetes.io/dockerconfigjson | Container registry credentials |
| kubernetes.io/service-account-token | Service account tokens (auto-generated) |
ConfigMap vs Secret
| Aspect | ConfigMap | Secret |
|---|---|---|
| Data type | Non-sensitive | Sensitive |
| Encoding | Plain text | Base64-encoded |
| Encrypted at rest? | No | Optional (must configure etcd encryption) |
| In-memory storage | On disk | tmpfs (in-memory) when mounted as volume |
| Example data | Database hostname, log level | Database password, API key |
The Base64 Trap
Critical exam point: Base64 encoding is NOT encryption. Anyone with access to the Secret can decode it. For actual encryption, you need to configure encryption at rest in etcd.
# This is encoding, NOT encryption:
echo -n "my-password" | base64
# Output: bXktcGFzc3dvcmQ=
# Anyone can decode it:
echo "bXktcGFzc3dvcmQ=" | base64 -d
# Output: my-password
Best Practices
| Practice | Why |
|---|---|
| Use ConfigMaps for non-sensitive data | Keep config separate from code |
| Use Secrets for sensitive data | Even though base64 isn’t true encryption, Secrets have stricter RBAC and audit logging |
| Don’t hardcode config in container images | Makes images portable across environments |
| Enable encryption at rest for Secrets | Protects Secret data in etcd |
| Use external secret managers for production | AWS Secrets Manager, HashiCorp Vault, Azure Key Vault |
Immutable ConfigMaps and Secrets
You can mark ConfigMaps and Secrets as immutable:
| Feature | Details |
|---|---|
| What it does | Prevents any changes after creation |
| Why use it | Protects against accidental updates; improves cluster performance (no watches needed) |
| To update | Delete and recreate the resource |
Key Takeaways for the Exam
- ConfigMaps store non-sensitive configuration data as key-value pairs
- Secrets store sensitive data — Base64-encoded but NOT encrypted by default
- Both can be consumed as environment variables or mounted volumes
- Base64 encoding ≠ encryption — Secrets need encryption at rest to be truly secure
- Separate config from code — this follows the Twelve-Factor App methodology
- Size limit for both: 1 MiB
- For production security, use external secret managers (Vault, AWS Secrets Manager)
What’s Next?
Let’s explore how Kubernetes decides where to place pods.
