ConfigMaps hold non-confidential settings; Secrets hold sensitive bytes but are not encrypted by default unless the cluster enables encryption at rest. This lab consumes both as environment values and read-only files.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
kubectl create namespace config-lab
kubectl -n config-lab create configmap app-config
--from-literal=LOG_LEVEL=info --from-literal=FEATURE_X=true
kubectl -n config-lab create secret generic app-secret
--from-literal=API_TOKEN="$(openssl rand -hex 24)"
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: v1
kind: Pod
metadata: {name: config-reader, namespace: config-lab}
spec:
containers:
- name: app
image: busybox:1.37
command: [sh, -c, 'env | grep LOG_LEVEL; sleep 3600']
envFrom: [{configMapRef: {name: app-config}}]
volumeMounts: [{name: secret, mountPath: /run/secrets, readOnly: true}]
volumes: [{name: secret, secret: {secretName: app-secret}}]
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl apply -f reader.yaml
kubectl -n config-lab logs config-reader
kubectl -n config-lab exec config-reader -- test -s /run/secrets/API_TOKEN
kubectl -n config-lab get secret app-secret -o jsonpath='{.data.API_TOKEN}' | base64 -d | wc -c
4. Troubleshooting
Base64 is encoding, not encryption. Restrict Secret access with RBAC, enable API encryption at rest, avoid printing values in CI logs, and restart or reload applications intentionally after updates.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete namespace config-lab
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
