Pod Security Standards & NetworkPolicies

RBAC controls who can change the cluster's desired state. These two features control something different: what a running container is actually allowed to do, and who it's allowed to talk to.

Pod Security Standards: constraining the container itself

Kubernetes defines three standard security profiles: Privileged (no restrictions — effectively opt-out), Baseline (blocks known privilege-escalation paths, a sane minimum), and Restricted (hardened: no root, no privilege escalation, a locked-down syscall filter). You apply one by labeling a namespace:

pod-security.kubernetes.io/enforce: restricted

No separate controller to install — this is built into API admission. Once set, any pod spec that violates the profile is rejected at kubectl apply time, not silently allowed and flagged later. You'll see this directly in the lab: applying a pod without the right securityContext into a restricted namespace never creates anything — the rejection message lists exactly which constraints it violated (running as root, missing seccomp profile, privilege escalation allowed).

Linux aside: most of what "restricted" enforces maps to real Linux primitives — runAsNonRoot is about the process's Linux UID (don't run as UID 0), seccompProfile restricts which syscalls the process can make at all, and dropping capabilities removes specific root-like powers (like binding privileged ports) without granting full root. Containers don't have their own permission model — they inherit Linux's.

NetworkPolicies: constraining who a pod can talk to

By default, every pod in a cluster can reach every other pod — namespaces don't restrict this (Module 2). A NetworkPolicy changes that, for the pods it selects, using the same label-selector pattern you've used since Module 2: podSelector picks which pods the policy applies to, then ingress/egress rules say what's allowed in or out — selected by pod labels, not IP addresses, so the rule keeps working as pods are replaced.

Default-deny, then allow by label

Apply default-deny + allow role=trusted

client-arole: untrusted

client-brole: trusted

✓

✓

🖥 serverapp: server

An empty podSelector: {} with policyTypes: [Ingress] and no ingress rules is a classic default-deny: it matches every pod in the namespace and allows nothing in. From there you add narrow ingress rules naming exactly which pods (by label) may reach which other pods — the same default-deny-then-allow shape as a security group, just selector-based instead of IP/CIDR-based.

One real caveat worth knowing: NetworkPolicy objects always exist as API objects, but enforcement is the CNI plugin's job, not the API server's. This cluster runs Calico specifically because it enforces NetworkPolicy; some CNIs (including kind's own default) silently accept the objects and do nothing. Always confirm your CNI actually enforces before trusting a policy in production.

The infrastructure analogy

A NetworkPolicy is a security group that follows the workload instead of an IP — you write "allow from anything labeled role: trusted" instead of "allow from 10.0.4.0/24." Pod Security Standards are closest to a hardened AMI/container baseline enforced at admission instead of discovered at runtime.

In the lab you'll trip a Restricted-namespace rejection and fix it, then prove a NetworkPolicy actually blocks (and selectively allows) real traffic — not just that the YAML applied.