Memory hook: Admission decides what enters; runtime settings constrain it; network policy limits where it talks.
Must remember
Pod Security Standards (PSS) define three policy levels. Privileged allows broad permissions; Baseline blocks common escalation paths while remaining broadly compatible; Restricted adds stronger hardening requirements. The standard describes permitted configuration; it is not itself a container runtime or network firewall.
Pod Security Admission (PSA) is the built-in mechanism for applying PSS with namespace labels. Modes are enforce (reject violations), audit (record violations in audit annotations) and warn (tell the requesting user). Modes can use different levels and version labels, such as enforcing baseline while warning about restricted. Restrict who may modify policy labels or exemptions. Admission does not retroactively evict every existing noncompliant Pod.
Recognize relevant Linux security settings: runAsNonRoot requires a non-root identity; allowPrivilegeEscalation: false restricts gaining more privilege through execution; capability dropping reduces Linux privileges; seccomp restricts system calls; AppArmor/SELinux constrain permitted operations through security profiles. A read-only root filesystem limits filesystem changes but requires planned writable locations. These controls complement each other. Privileged containers bypass important protections. The exact PSS checks vary with policy version and operating system; do not assume read-only root filesystem is a universal Restricted requirement.
Admission operates after authentication/authorization on applicable API operations. Mutating admission may adjust an object; validating admission can reject it. Policies can require approved registries, image signatures or organizational labels. Webhook credentials, TLS, permissions, availability and failure policy matter: fail-open can admit unchecked changes; fail-closed can block legitimate changes during an outage. Admission does not scan every network packet or continuously evaluate all running processes.
NetworkPolicy selects Pods and controls allowed ingress and/or egress. A compatible network implementation must enforce it. Pods are ordinarily non-isolated in a direction until a policy selects them for that direction. Allowed traffic is the union of applicable policies. If both ends are isolated, the source's egress and destination's ingress must both permit the connection; allowed replies are handled as part of that connection.
Within one peer entry, namespaceSelector plus podSelector means both must match. Separate peer entries are alternatives. A Pod selector alone selects peers in the policy's namespace. Be deliberate about empty selectors and allow DNS when restricting egress. Standard NetworkPolicy is primarily L3/L4 policy, not HTTP user authorization or automatic encryption.
A namespace gives administrative scope; segmentation requires RBAC, network policy, admission, quotas and appropriate node/runtime boundaries together. Strongly hostile tenants may require separate clusters or stronger isolation than shared namespaced workloads.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Block newly submitted privileged workloads | Use appropriate enforced Pod Security Admission or equivalent admission policy. |
| Preview tighter security before enforcement | Use warn/audit with the proposed level and review incompatible workloads. |
| Allow frontend Pods to contact only a database and DNS | Select explicit egress destinations and required ports; also satisfy destination ingress. |
| Require trusted signed releases | Use artifact-verification admission policy; PSS alone does not verify image signatures. |
Traps
- Warn and audit do not reject a Pod merely because it violates their level.
- NetworkPolicy YAML has no enforcement effect without a supporting network plugin.
- An ingress allow at the destination does not override a denying source egress policy.
- PSS Restricted does not automatically mean every possible hardening setting is enabled.
Active recall
1. Which PSA mode actually rejects a violating Pod request?
Enforce. Warn informs the client and audit adds evidence without enforcing that level.
2. Do two NetworkPolicies override one another according to creation order?
No. Their allowed traffic is combined for selected Pods; order is not the model.
3. A peer contains a namespace selector and Pod selector in the same item. AND or OR?
AND. The Pod must match within a namespace that also matches. Separate peer items provide alternatives.
4. Can admission replace application user authorization?
No. Admission controls applicable Kubernetes API object operations; the application still authorizes its own requests.
5. A restrictive PSA label was added. Were all existing violating Pods necessarily deleted?
No. Admission checks applicable requests; existing Pods are not automatically evicted simply by applying the label.