Application Environment, Configuration and Security
Configuration injection, resource sizing, and least-privilege identity.
ConfigMaps and Secrets
Create them with kubectl create configmap app --from-literal=K=V --from-file=./conf or kubectl create secret generic creds --from-literal=token=abc --from-file=./tls.crt. Secrets also come as docker-registry and tls types. Consume via env.valueFrom.configMapKeyRef/secretKeyRef, envFrom, or a volume mount. Trap: environment variables are frozen at container start - editing the ConfigMap does not change a running container's env, and envFrom does not refresh either. Volume-mounted keys do update, eventually. A missing key without optional: true yields CreateContainerConfigError. Secrets are only base64-encoded in data, not encrypted, unless encryption at rest is configured; stringData accepts plaintext on write.
Resources and QoS
requests drive scheduling; limits are enforced by the kubelet. CPU limits cause throttling, memory limits cause OOMKilled. Requests equal to limits everywhere gives Guaranteed QoS; none at all gives BestEffort.
Identity and RBAC
Pods use a ServiceAccount, mounted by default (automountServiceAccountToken: false disables it). RBAC: Role plus RoleBinding is namespaced; ClusterRole plus ClusterRoleBinding is cluster-wide. Build rules quickly with kubectl create role reader --verb=get,list --resource=pods and verify with kubectl auth can-i list pods --as=system:serviceaccount:dev:reader.
SecurityContext
Pod-level fields (runAsUser, fsGroup) inherit into containers; container-level fields win. Harden with allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, and capabilities: {drop: [ALL]}.
Trap: runAsNonRoot: true against an image whose USER is root fails at container creation with CreateContainerConfigError.
Worked example: kubectl exec -it pod -- id confirms the effective UID after applying runAsUser: 1000.