Kubernetes ConfigMaps and Secrets — Complete Guide
In this tutorial, you'll learn about Kubernetes ConfigMaps and Secrets. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.
What You'll Learn
Manage configuration and secrets in Kubernetes — ConfigMaps for non-sensitive data, Secrets for sensitive data, and how to inject them into pods.
Why It Matters
Hardcoding config is bad practice and a security risk. ConfigMaps and Secrets let you manage configuration externally and safely.
Real-World Use
Storing database connection strings, API keys, feature flags, and configuration files that change between environments.
ConfigMap
A ConfigMap stores non-sensitive configuration data as key-value pairs or files.
Create from Literal Values
kubectl create configmap app-config \
--from-literal=APP_ENV=production \
--from-literal=LOG_LEVEL=info \
--from-literal=MAX_CONNECTIONS=100
Create from File
# app.properties
APP_ENV=production
LOG_LEVEL=info
kubectl create configmap app-config \
--from-file=app.properties
ConfigMap YAML
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
APP_ENV: production
LOG_LEVEL: info
MAX_CONNECTIONS: "100"
app.properties: |
APP_ENV=production
LOG_LEVEL=info
Secret
A Secret stores sensitive data (base64 encoded):
kubectl create secret generic db-secret \
--from-literal=DB_HOST=postgres.prod.svc \
--from-literal=DB_USER=admin \
--from-literal=DB_PASSWORD=s3cret! \
--from-literal=DB_NAME=myapp
Secret YAML
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
data:
DB_HOST: cG9zdGdyZXMucHJvZC5zdmM= # base64
DB_USER: YWRtaW4=
DB_PASSWORD: czNjcmV0IQ==
Note: base64 is not encryption. Enable encryption at rest and use RBAC.
Using ConfigMap and Secret in Pods
As Environment Variables
apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app
image: my-app
env:
# From ConfigMap
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV
# From Secret
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: DB_PASSWORD
envFrom:
- configMapRef:
name: app-config
- secretRef:
name: db-secret
As Mounted Files
spec:
containers:
- name: app
image: my-app
volumeMounts:
- name: config-volume
mountPath: /etc/config
- name: secret-volume
mountPath: /etc/secrets
readOnly: true
volumes:
- name: config-volume
configMap:
name: app-config
- name: secret-volume
secret:
secretName: db-secret
Each key becomes a file:
/etc/config/APP_ENV # Contains "production"
/etc/config/app.properties # Contains the file content
/etc/secrets/DB_PASSWORD # Contains the password
Best Practices
| Practice | Why |
|---|---|
| Use Secrets, not ConfigMaps, for sensitive data | Avoid accidental exposure |
| Enable encryption at rest | Protect secrets in etcd |
| Use RBAC to restrict access | Not everyone needs DB credentials |
| Use external secrets (Sealed Secrets, External Secrets Operator) | GitOps-friendly |
| Audit access to Secrets | Detect breaches |
| Use immutable ConfigMaps/Secrets when possible | Performance + safety |
Immutable ConfigMaps and Secrets
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
immutable: true
data:
APP_ENV: production
Immutable resources can't be changed — you must create a new one. This prevents accidental updates and improves performance.
External Secrets Operator
For managing secrets from external providers (AWS Secrets Manager, HashiCorp Vault):
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: db-secret
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets
kind: SecretStore
target:
name: db-credentials
data:
- secretKey: password
remoteRef:
key: /prod/db/password
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro