A company's public marketing site and its payments service run in the same Kubernetes cluster. The marketing site is compromised. Explain the exposure and design the containment.

1. State the default: in Kubernetes, pod-to-pod traffic is unrestricted, so being off the public internet is not isolation — the attacker now has network reach to the payments service. 2. Layer one, network: default-deny NetworkPolicies per namespace, with explicit allow rules for the flows that must exist, so the marketing pod cannot open a connection to payments at all. 3. Layer two, identity: mutual TLS through a service mesh so every call carries a verifiable workload identity and network position stops being the credential. 4. Layer three, authorization: per-service policies specifying which identities may call which routes and methods, so even a valid mesh identity cannot call arbitrary endpoints. 5. Layer four, application: the payments service still authorises every request on its own and never trusts a caller-supplied principal. 6. Constrain the blast radius further — separate namespaces, distinct service accounts with minimal RBAC, no cluster-admin tokens mounted, and separate node pools or clusters for the payment tier if the regime demands it. 7. Add detection: egress restrictions plus alerting on denied policy events, since the first sign of lateral movement is a burst of refused connections. 8. Summarise the property achieved: one breached workload no longer implies a breached cluster.