11 / Isolation is a stack, not a namespace label

Scroll the diagram sideways for readable labels.

Learning objective and isolation model verified

Multi-tenancy requires both control-plane and data-plane isolation. Namespaces scope many API resources but do not create independent kernels. Dedicated nodes reduce co-location but can still share cluster services; stronger isolation may justify sandboxed execution or separate clusters, with extra cost and operations.

Network-policy mechanism verified

Without applicable NetworkPolicies, Pod ingress and egress are allowed by default. Policies require a supporting enforcement implementation and primarily express L4 rules. Default-deny egress also blocks DNS unless allowed. IAM, security groups, NetworkPolicy and business authorization cover different scopes.

Worked example synthesis

In the insurance exercise, use tenant-scoped application queries even if each team has its own namespace. Restrict deployers and service accounts to their required API operations. Add explicit dependency flows before applying default-deny. On a Pod Identity workload, include the identity-agent credential path; on private AWS access, verify required service endpoints.

Decision and pitfall synthesis

A tenant allowed to run arbitrary untrusted code changes the threat model. Namespace-only separation is too weak for that assumption; evaluate sandbox or dedicated-cluster designs. A toleration only permits scheduling onto a tainted node and does not, by itself, force exclusive placement. Enforce the intended placement and admission constraints.

Further improvement synthesis

Write a permission matrix and a network dependency map, then test denied access as well as allowed access. Verify the real policy implementation on your chosen EKS compute mode. Treat base64 values and read access to Secret objects as sensitive, and keep plaintext secret manifests out of the delivered examples.