Config, Secrets & Security
Configuration injection, identity, authorization, admission control, and production hardening practices.
What is a ConfigMap and how do you inject its data into a Pod?
A ConfigMap stores non-sensitive key-value configuration. Inject via env/envFrom (keys become environment variables) or mount as files with volumes/volumeMounts (supports multi-line files via subPath). ConfigMap updates do not automatically restart Pods - use a reloader sidecar, Argo CD sync waves, or a rolling restart to pick up changes.
How are Secrets different from ConfigMaps, and are Secrets actually secure?
Secrets store sensitive data (passwords, tokens, TLS certs) and are base64-encoded in etcd - not encrypted by default. Enable encryption at rest via EncryptionConfiguration on the API server. Prefer stringData over manual base64 encoding. For production, use External Secrets Operator, Sealed Secrets, or Vault rather than committing Secrets to Git or relying on etcd alone.
What is a ServiceAccount and why should you avoid the default one?
Every Pod runs as a ServiceAccount - an in-cluster identity for API access and cloud IAM (via workload identity annotations like eks.amazonaws.com/role-arn). The default ServiceAccount exists in every namespace with a mounted token. Never run production workloads with it; create dedicated ServiceAccounts with minimal RBAC. Set automountServiceAccountToken: false when the Pod does not need Kubernetes API access.
Explain RBAC: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.
RBAC controls who (subjects: User, Group, ServiceAccount) can perform what (verbs) on which resources. A Role defines permissions within a namespace; a ClusterRole is cluster-wide. RoleBinding links subjects to a Role in one namespace; ClusterRoleBinding grants cluster-wide access. Debug with kubectl auth can-i create pods --as=system:serviceaccount:ns:sa-name.
What are the three Pod Security Standards levels?
Pod Security Admission (built-in since K8s 1.25) enforces three levels via namespace labels: privileged - unrestricted, for system components only; baseline - blocks known privilege escalations (no host namespaces, no privileged containers); restricted - heavily hardened (non-root, drop all capabilities, read-only root filesystem, seccomp RuntimeDefault). Label namespaces with pod-security.kubernetes.io/enforce=restricted for production apps.
What are admission controllers and how do mutating vs validating differ?
Admission controllers intercept API requests after authentication and authorization but before persistence. Mutating controllers modify objects (inject sidecars, set defaults, add resource limits). Validating controllers reject non-compliant requests (Pod Security, resource policy). Built-in examples: NamespaceLifecycle, LimitRanger, PodSecurity. Custom policies often use OPA Gatekeeper or Kyverno.
How would you enforce custom policies with OPA Gatekeeper?
Gatekeeper runs validating and mutating webhooks backed by Rego policies. Define a ConstraintTemplate (the Rego logic) and a Constraint (the enforcement instance). Common policies: require labels (app, team, env), block :latest image tags, enforce resource requests/limits, deny hostPath volumes. Gatekeeper complements Pod Security Standards with organization-specific rules.
What does a production-hardened Pod securityContext look like?
At Pod level: runAsNonRoot: true, seccompProfile: RuntimeDefault. Per container: allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, runAsUser: 10001 (non-zero UID), capabilities: drop: ["ALL"]. Add an emptyDir mount for writable temp paths if the app needs them. Combine with NetworkPolicies, minimal ServiceAccount RBAC, and image scanning in CI.
How do you manage secrets in GitOps workflows without storing plaintext?
Options: Sealed Secrets - encrypt Secrets with a cluster public key; only the controller can decrypt. External Secrets Operator - sync from AWS Secrets Manager, GCP Secret Manager, or Vault into native K8s Secrets at runtime. SOPS - encrypt YAML files in Git, decrypted by Flux or Argo CD. Never commit plaintext Secrets; rotate credentials and audit Secret access via RBAC.
What is the principle of least privilege for Kubernetes RBAC in practice?
Grant only the verbs and resources each actor needs. App ServiceAccounts should not have create/delete pods unless they are operators. Developers get get/list/watch in dev namespaces, not cluster-admin. Use namespace-scoped Roles over ClusterRoles when possible. Audit bindings regularly; remove unused ServiceAccounts. Combine RBAC with admission policies so even over-permissioned tokens cannot deploy privileged Pods.
How does Kubernetes encrypt Secrets at rest?
Configure EncryptionConfiguration on the API server with providers like aescbc or kms (envelope encryption via AWS KMS, GCP KMS, Azure Key Vault). Secrets are encrypted before writing to etcd. The identity provider serves as fallback for unencrypted legacy data during migration. Verify with kubectl get secrets -o yaml - values should not be readable from etcd directly without the encryption key.
What network and runtime controls complement Pod Security Standards?
Pod Security Standards are necessary but not sufficient. Add NetworkPolicies for default-deny ingress/egress. Use Pod Security Standards + admission webhooks for policy enforcement. Enable audit logging on the API server. Run vulnerability scanning on images (Trivy, Grype). Consider runtime security (Falco) for anomaly detection. Restrict node SSH and use IRSA/workload identity instead of long-lived cloud credentials in Pods.