Shared Cluster, PCI Scope, and a New Internet-Facing Tenant
PaymentsCo runs a single 60-node managed Kubernetes cluster on a public cloud. Six teams share it through namespaces: payments, checkout, identity, marketing, staging, and platform. The payments namespace processes cardholder data and is in PCI DSS scope; the cloud provider manages the control plane and etcd. The platform team has four engineers and no budget for per-team clusters. A recent pen test found that a compromised pod in staging could reach the payments database service because a default-allow NetworkPolicy exists cluster-wide, and several teams reuse the same image pull secret. Marketing now wants to deploy internet-facing campaign sites into a new namespace. The CISO asks whether namespace isolation is enough for PCI workloads and what must change before marketing is onboarded. Uptime target is 99.95%, and the next audit is in 90 days.
1. Classify the controls involved in this scenario into cloud-provider, cluster, and workload layers, and explain why the boundary matters for PCI scope.
Read the worked answer
The boundary matters because PCI scope follows data and the controls that protect it, not just a namespace label.
- Provider layer: physical security, hypervisor, managed control plane, etcd availability, and underlying network. The provider supplies these, but the customer still owns API access decisions and workload behavior.
- Cluster layer: authentication and authorization, admission control, audit logging, CNI policy enforcement, node OS hardening, secrets encryption with KMS, and RBAC. These are shared-cluster controls that can cross namespace boundaries.
- Workload layer: pod security context, image provenance, service-account use, secret handling, and application authentication.
A shared cluster means a cluster-scoped compromise or node-level access can cross namespaces, so the PCI boundary must be enforced with cluster and workload controls, not namespaces alone. Evidence should show each layer's owner, the control, and a test result. The customer cannot point to the managed control plane as proof that payments are segmented.
2. Is namespace isolation sufficient to keep the payments namespace in PCI scope while sharing the cluster? Justify your answer and name the minimum compensating controls.
Read the worked answer
No. Namespaces are an API scoping mechanism, not a security boundary against a cluster-admin, a node-level attacker, or a shared CNI and ingress path. In this cluster, cluster-wide default-allow policy, reused image pull secrets, and shared node pools mean a staging pod can reach payments.
Minimum compensating controls: default-deny NetworkPolicy with explicit payments ingress and egress; a dedicated node pool for payments with taints and tolerations; separate service accounts and image pull secrets per namespace; Pod Security Admission restricted; secrets encrypted at rest with customer-managed KMS and not exposed as environment variables; API audit logs; least-privilege RBAC with periodic review; and admission control blocking privileged and hostPath pods.
If those cannot be met within 90 days, move payments to a dedicated cluster. PCI segmentation must be defensible against a realistic attacker, not just a misconfigured pod in another namespace.
3. What conditions would you require before the marketing namespace is allowed to host internet-facing sites on this cluster?
Read the worked answer
Conditions: marketing must have its own service account and image pull secret, resource quotas and limit ranges, default-deny network policy with no path to payments, PSA baseline at minimum and restricted where possible, and an admission policy that blocks hostPath, privileged, and unsigned images. Ingress must terminate outside the payments path, and marketing must not share node pools with payments if the risk assessment says node-level escape is credible.
Also require audit logging to a central immutable store, a documented namespace onboarding checklist, and a network policy test in CI. I would not accept namespace-only isolation just because marketing is less regulated; internet-facing workloads raise the likelihood of compromise, so they increase the need for segmentation.
Onboard only after a tabletop test and a pen-test retest of the staging-to-payments path. The reasoning is that the new tenant adds attack surface, so the control set must reduce both lateral movement and public exposure.