Skip to content
intermediate Phase 14 · Production Operations

Namespace Isolation

Configure namespace isolation with RBAC, network policies, and resource quotas.

45m
0 problems
Topic Progress 0%

Four Layers of Isolation

Four Layers of Isolation

A namespace is fenced along four independent axes — configure all of them:

  1. API access — Role/RoleBinding restrict what identities may do inside the namespace
  2. Network — NetworkPolicy (CNI-enforced) controls pod-to-pod flow, cluster-wide once selected
  3. Resources — ResourceQuota/LimitRange prevent one tenant's workloads from starving others
  4. 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?

Question 1 options

2. What indicates a NetworkPolicy is not being enforced?

Question 2 options

3. Why use a RoleBinding instead of a ClusterRoleBinding for a namespace tenant?

Question 3 options

Flashcards

Question

Isolation layers

Answer

API (RBAC), network (NetworkPolicy), resources (quota/limitrange), process (Pod Security Admission).

Question

default-deny NetworkPolicy

Answer

podSelector: {} with policyTypes blocks all traffic until explicit allow policies are added.

Question

DNS egress exception

Answer

Always allow egress UDP/TCP 53 to kube-dns under default-deny or name resolution fails.

Question

PSA modes

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.

Continue Learning