Four Layers of Isolation
Four Layers of Isolation
A namespace is fenced along four independent axes — configure all of them:
- API access — Role/RoleBinding restrict what identities may do inside the namespace
- Network — NetworkPolicy (CNI-enforced) controls pod-to-pod flow, cluster-wide once selected
- Resources — ResourceQuota/LimitRange prevent one tenant's workloads from starving others
- Process posture — Pod Security Admission labels enforce baseline/restricted profiles at admission
Miss one layer and the boundary has a hole: open RBAC leaks data, missing egress rules leak traffic, no quota enables noisy-neighbor starvation, and privileged pods undermine everything else.
Concrete Policies
Concrete Policies
Deny ingress by default, then allow precisely:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny-ingress, namespace: team-a }
spec:
podSelector: {}
policyTypes: [Ingress, Egress]
---
# deny-all above; also allow egress UDP/TCP 53 to kube-dns or DNS breaks
RBAC with least privilege:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: { name: developer, namespace: team-a }
rules:
- apiGroups: [""]
resources: [pods, pods/log, services]
verbs: [get, list, create, delete]
Bind it with a RoleBinding to a group; enforce PSA with pod-security.kubernetes.io/enforce: restricted.`
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Silent no-op policies. Without a CNI that enforces NetworkPolicy (or the wrong mode selected), rules apply to nothing — verify with a live canary pod pair before declaring isolation done.
DNS starvation. Default-deny egress without a DNS allow breaks every hostname resolution in the namespace — the classic self-inflicted outage.
ClusterRoleBindings. A system:authenticated ClusterRoleBinding granting cluster-wide read undoes namespace scoping entirely.
Restricted PSA rejection. enforce: restricted requires dropped capabilities, seccomp, and non-root — workloads fail admission until securityContext is fixed; stage with audit/warn first.
Interview angle: given "tenant A reached tenant B's service," walk the checks: endpoints/selectors → NetworkPolicy enforcement → identity/RBAC → mesh policy — and say which you would prove first.
Quiz
1. A default-deny egress policy broke pod DNS. What is missing?
2. What indicates a NetworkPolicy is not being enforced?
3. Why use a RoleBinding instead of a ClusterRoleBinding for a namespace tenant?
Flashcards
Question
Isolation layers
Click to reveal answer
Answer
API (RBAC), network (NetworkPolicy), resources (quota/limitrange), process (Pod Security Admission).
Question
default-deny NetworkPolicy
Click to reveal answer
Answer
podSelector: {} with policyTypes blocks all traffic until explicit allow policies are added.
Question
DNS egress exception
Click to reveal answer
Answer
Always allow egress UDP/TCP 53 to kube-dns under default-deny or name resolution fails.
Question
PSA modes
Click to reveal answer
Answer
enforce (reject), warn (admit + warn), audit (log) — staged rollout of baseline/restricted profiles per namespace label.
Revision Notes
Key Takeaways
- 1. Isolation requires all four layers working — RBAC, network policy, quota, and PSA
- 2. Deny-by-default with explicit allows; prove enforcement with live tests
- 3. Bindings determine scope; stage PSA with warn/audit before enforce
Interview Tips
- • Diagnose cross-tenant access as a layered checklist, naming the proof command per layer
- • Explain why restricted PSA breaks naive workloads and how you would roll it out safely
Cheat Sheet
Fence a namespace: Role/RoleBinding (API), default-deny NetworkPolicy + DNS allow (network), Quota+LimitRange (resources), PSA restricted (process). Verify policy enforcement live; bindings set scope.