Memory hook: Admission constrains configuration; identity constrains access.
Must remember
Pod Security Standards define privileged, baseline and restricted profiles. Pod Security Admission namespace labels select enforcement, audit and warning behavior with version choices. Audit/warn modes report issues without necessarily blocking admission; enforce mode rejects noncompliant creation/update as documented. Existing workloads require deliberate review and rollout. Removed PodSecurityPolicy is not the current native admission mechanism.
Memorize the label shape: pod-security.kubernetes.io/enforce=restricted and pod-security.kubernetes.io/enforce-version=v1.35 select a level and policy version; use the version required by the task. The same prefix supports warn and audit. Inspect with kubectl get namespace team --show-labels. Updating a namespace label does not evict its existing Pods; verify the resulting behavior with an appropriately scoped admission test and a controlled workload rollout.
Minimize Secret access, avoid writing secrets to logs/images and disable unused service-account token mounts. Encrypt supported API data at rest and protect encryption-provider keys/configuration. Changing encryption configuration does not automatically rewrite every existing stored object; follow the documented migration/rotation procedure and keep recovery keys available as needed.
Multi-tenant isolation combines RBAC, quotas, network policy, Pod security and suitable node/runtime boundaries. Namespace separation alone does not prevent all cross-tenant access. Test both allowed and denied paths with the actual workload identity.
Service-mesh mTLS can authenticate/encrypt workload traffic when correctly configured. Cilium encryption and Istio mTLS have different implementation scopes; verify which traffic is protected and how identities/keys are managed. Encryption does not decide whether a service is authorized to call another: apply the corresponding authorization policy. Strict-mode rollout must account for workloads that do not yet participate.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Reject privileged application Pods | Appropriate Pod Security Admission enforcement. |
| Protect persisted Secret objects | Encryption-at-rest configuration plus restricted API/key access. |
| Authenticate service-to-service traffic | Configured workload mTLS plus authorization policy. |
Traps
- Warning labels do not equal enforcement.
- mTLS does not automatically implement business authorization.
Active recall
1. Three Pod Security profiles?
Privileged, baseline and restricted.
2. Audit versus enforce?
Record violations versus reject violating requests under the configured admission behavior.
3. Does enabling encryption rewrite old data immediately?
No; existing objects need the documented rewrite/migration process.
4. Why keep identity and network controls?
Encryption alone does not restrict who may access a resource.
5. Why stage strict mTLS?
Nonparticipating clients may fail until identity and protocol configuration align.