Key Takeaways
- If CDE pods run on a cluster, the cluster is in scope: control plane, nodes, every workload that can reach those pods, the registry, the pipeline, and every identity with API access
- On EKS, AKS, GKE and ACK the provider's AOC covers the control plane; nodes, workloads, RBAC, network policy, images, secrets and logging configuration are yours
- A namespace is not segmentation. Enforced NetworkPolicy, mesh authorization policy or separate clusters are, and each must be penetration-tested under Requirement 11.4.5
- The recurring findings are configuration gaps: cluster-admin bound to broad groups, secrets in environment variables, flat cluster networks, public control-plane endpoints and short audit-log retention
Does Running the CDE on Kubernetes Change PCI DSS Scope?
Yes, and usually by more than teams expect. PCI DSS scope is defined by systems that store, process or transmit cardholder data, plus any system that can connect to them or affect their security. On Kubernetes, that second category is large. Once a payment service runs as a pod, the following are in scope by default:
The cluster itself. The API server, etcd (which stores your Secrets), the scheduler, controller manager and every worker node the CDE pods can be scheduled onto. If node pools are not pinned with taints, node selectors or affinity rules, that means every node in the cluster.
Every workload on the same network. Kubernetes networking is flat by default: any pod can reach any other pod on any port. Without enforced NetworkPolicy, every workload in the cluster is a connected-to system and therefore in scope, whichever namespace it lives in.
Identities with API access. Every user, group, service account and CI/CD identity that can exec into CDE pods, read Secrets in CDE namespaces, or apply manifests that deploy to them. Cluster-admin bindings anywhere in the cluster are in scope for Requirement 7 and 8 testing.
The supply chain. The container registry, the build pipeline, image signing infrastructure and the admission controllers that decide what is allowed to run. These determine what code executes inside the CDE, so a QSA will examine them under Requirements 6 and 2.
The PCI Security Standards Council's Guidance for Containers and Container Orchestration Tools (information supplement, September 2022) sets out these principles in vendor-neutral terms across sixteen areas of recommended practice. It is not a set of requirements, but QSAs use it as the reference for what "industry-accepted" looks like in a containerised CDE.
One point deserves emphasis because it is the single most common misunderstanding we encounter: a Kubernetes namespace is a logical grouping for names, quotas and RBAC scope. It is not a network boundary. Placing CDE workloads in a namespace called payments does nothing to reduce scope unless a control that actually restricts traffic is attached to it.
Who Owns What on Managed Kubernetes?
Managed Kubernetes services move the control plane behind the provider's line of the shared responsibility model. The provider runs and patches the API server, etcd and the core controllers, and that portion is covered by its PCI DSS Attestation of Compliance. Everything the customer configures or deploys on top remains the customer's, and the QSA will evidence it from your environment:
| Layer | Provider Handles | You Handle |
|---|---|---|
| Control plane | API server, etcd (including encryption at rest), scheduler, controller manager, version patching | Endpoint exposure (public or private), authorised networks, audit-log enablement and routing, Secrets encryption key (KMS envelope encryption where offered) |
| Worker nodes | Base image availability, managed node-pool upgrade mechanics | Choosing to upgrade, node OS hardening (CIS benchmark), node IAM roles, disk encryption, metadata-service protection |
| Cluster configuration | Defaults | RBAC, NetworkPolicy, Pod Security admission, resource quotas, admission controllers, namespaces |
| Workloads and images | Nothing | Image contents and vulnerabilities, signing, registry access, Secrets handling, application code, TLS between services |
| Logging and monitoring | Generating control-plane logs | Turning audit logging on, routing to a retained store, container and node log collection, review and alerting |
The provider-specific mechanics differ, and the differences matter for evidence. The table below is how the four managed services handle three things every assessment asks about:
| Service | Control-Plane Audit Logs | Node OS Patching | Cloud-Layer API Trail |
|---|---|---|---|
| Amazon EKS | Off by default; enable the audit and authenticator log types to CloudWatch Logs | Managed node groups: you trigger AMI updates; Fargate profiles: AWS patches | CloudTrail (EKS API calls and IRSA-issued credentials) |
| Azure AKS | Diagnostic settings: kube-audit or kube-audit-admin to Log Analytics or storage | Node image auto-upgrade channel is opt-in; you select the cadence | Azure Activity Logs and Entra ID sign-in logs |
| Google GKE | Admin Activity audit logs on by default in Cloud Logging; Data Access logs must be enabled; retention set on the log bucket | Node auto-upgrade on by default in release channels | Cloud Audit Logs at project and organisation level |
| Alibaba ACK | API server audit logs collected to Simple Log Service (SLS) when enabled; retention configured on the Logstore | Managed node pools support automatic OS patching; you enable it | ActionTrail (ACK and RAM API calls) |
Check the provider's current documentation before relying on any default, because these settings change between versions. What does not change is the assessment logic: if the log is not enabled, routed to a store you control, and retained for twelve months, Requirement 10 is not met, and no amount of provider validation covers that gap. The provider guides in this series cover the cloud-account layer in depth: AWS, Azure, Google Cloud and Alibaba Cloud.
Dedicated Cluster or Shared Cluster With Hard Multi-Tenancy?
This is the scoping decision that sets the cost of every assessment that follows. There are two defensible designs.
A dedicated CDE cluster. Payment workloads run in their own cluster, in a dedicated cloud account, subscription or project, with its own node pools, registry, and pipeline. The cluster boundary is the scope boundary. The QSA still tests segmentation between this cluster and everything it talks to, but the question of what is inside the cluster is answered by design. In our experience this is the cheaper option to assess and to keep compliant year on year.
A shared cluster with hard multi-tenancy. PCI and non-PCI workloads share a cluster, and isolation is engineered. For a QSA to accept this as segmentation, all of the following need to be in place and demonstrable:
A default-deny NetworkPolicy in every CDE namespace with explicit ingress and egress allow rules, enforced by a CNI that implements the policy (Calico, Cilium, Azure CNI with network policy, GKE Dataplane V2, Terway on ACK). Optionally a service mesh with mutual TLS and authorization policies, which adds identity-based control on top of IP-based policy. Dedicated node pools for CDE workloads, using taints, tolerations and node affinity so that CDE pods never share a kernel with non-CDE pods. Separate RBAC: no binding that grants write or exec access across CDE and non-CDE namespaces. Separate Secrets, registries and pipelines, so that a compromise of a non-CDE build cannot push into the CDE.
Whichever design you choose, the segmentation must be tested. Requirement 11.4.5 requires penetration testing of segmentation controls at least every 12 months and after changes; Requirement 11.4.6 makes it every six months for service providers. A NetworkPolicy manifest is a configuration artefact; the test report is the evidence that it works. See our PCI DSS penetration testing service for what a segmentation test involves, and cloud penetration testing for cluster-specific attack paths.
A test we run in every cluster engagement: from a pod in a non-CDE namespace, attempt to reach CDE service endpoints, the node metadata service, and the API server with the pod's default service-account token. If any of the three succeeds, the cluster is flat for scoping purposes, regardless of what the architecture diagram says.
Mapping PCI DSS v4.0.1 Requirements to Cluster Controls
The mapping below is the starting point our assessors use for a Kubernetes-hosted CDE. It covers the cluster layer; the cloud-account layer (IAM, KMS, cloud logging) is mapped in the provider guides.
| PCI DSS Requirement | Cluster Control | Typical Evidence |
|---|---|---|
| Req 1 — Network security controls | Default-deny NetworkPolicy, ingress controller and load-balancer exposure, egress control, cloud firewall or security groups on nodes | Policy manifests per namespace, CNI enforcement proof, ingress inventory, segmentation test report |
| Req 2 — Secure configurations | CIS Kubernetes Benchmark for nodes and cluster, Pod Security admission (restricted profile), no privileged or host-namespace pods, read-only root filesystems | Benchmark scan results, admission policy manifests, exceptions register |
| Req 3 & 4 — Protect stored and transmitted data | Secrets backed by KMS envelope encryption or an external secrets manager (Secrets Manager, Key Vault, Secret Manager, Alibaba KMS), TLS between services (mesh mTLS or application TLS), no PAN in logs or ConfigMaps | Encryption configuration, key-management procedures, TLS configuration, data-discovery results |
| Req 5 & 6 — Malware and secure software | Image vulnerability scanning in the pipeline and registry, image signing with admission enforcement (Binary Authorization, Sigstore or equivalent), base-image patch cadence, runtime threat detection | Scan reports with remediation dates, signing policy, admission rejection logs, patch records |
| Req 7 & 8 — Access control and authentication | RBAC with least-privilege roles, no wildcard ClusterRoles, workload identity (IRSA, Workload Identity, Microsoft Entra Workload ID, RRSA) instead of long-lived keys, MFA on the cloud identity used for kubectl, service-account token automounting disabled | RBAC bindings export, access review records, identity provider MFA configuration |
| Req 10 — Logging and monitoring | API server audit logs shipped to CloudWatch, Azure Monitor, Cloud Logging or SLS; node and container logs collected; 12-month retention with three months online; alerting on cluster-admin actions and exec sessions | Audit policy and diagnostic settings, retention configuration, sample review records |
| Req 11 — Security testing | Quarterly internal scans of nodes and exposed services, ASV scans of ingress addresses, annual cluster penetration test, segmentation test, file-integrity or change detection on critical configuration | Scan reports, ASV attestations, penetration and segmentation test reports |
Two clarifications save arguments during assessments. First, image scanning is a Requirement 6 control, not a Requirement 11.3 scan: it finds known vulnerabilities before deployment, but the quarterly internal and external scans of the running environment are still required. Second, the penetration test must include the cluster: API server exposure, RBAC escalation paths, pod-to-node escape attempts, metadata-service access and lateral movement between namespaces, not only the web application in front of it.
The Findings We See on Kubernetes-Hosted CDEs
The same six findings recur across the cluster-hosted environments our QSAs review. None of them is a Kubernetes flaw; each is a default that nobody changed.
1. cluster-admin bound to broad groups. The identity provider group used to bootstrap the cluster, often "engineering" or "devops", still carries a cluster-admin ClusterRoleBinding a year later. Requirement 7 expects role-based access by job function and periodic reviews; a binding that grants every developer full control of the CDE fails both.
2. Secrets in environment variables and ConfigMaps. Database passwords and API keys injected as plain environment variables, visible to anyone who can describe the pod or read the deployment manifest in the repository. Kubernetes Secrets without KMS envelope encryption are base64, not encryption. Requirement 3 and 8 findings follow.
3. Workloads in the default namespace. Payment services deployed to default alongside test tooling and whatever else was applied during a demo. Scope becomes impossible to draw.
4. A public control-plane endpoint. The API server reachable from the internet, protected only by credentials. Every managed service supports private endpoints or authorised-network restrictions; leaving the endpoint public is a Requirement 1 finding and a favourite penetration-test entry point.
5. No NetworkPolicy, so a flat cluster. The most consequential finding. Without a default-deny policy the entire cluster is one network, every workload is in scope, and the segmentation claimed in the scope document does not exist.
6. Audit logs off or retained for 30 days. EKS audit log types not enabled, AKS diagnostic settings never configured, GKE Data Access logs disabled, or a log bucket with default retention. Requirement 10 expects twelve months of history, and the gap is invisible until the QSA asks for a log from eight months ago.
A seventh appears often enough to mention: images with critical, known-exploitable CVEs running in production because the scanner reports to a dashboard nobody owns. Requirement 6.3.3 expects critical and high vulnerabilities to be patched within one month of release.
All of these are cheaper to find in a pre-assessment gap analysis than during the assessment. Our PCI DSS assessment service covers cluster-hosted scoping and gap analysis before the ROC engagement begins.
Evidence for a Kubernetes CDE, and What Can Be Automated
Cluster evidence is unusually well suited to export, because almost everything a QSA needs is a declarative object or a log. The evidence set we ask for at the start of a Kubernetes engagement is:
RBAC: every ClusterRole, ClusterRoleBinding, Role and RoleBinding touching CDE namespaces. Network: NetworkPolicy objects per namespace and proof of the CNI in use. Admission: Pod Security admission levels per namespace and any policy-engine constraints (Gatekeeper, Kyverno) with their audit results. Logging: the audit policy or diagnostic settings, the destination, and the retention configuration. Supply chain: registry access policy, image signing configuration and the latest scan report for every image running in CDE namespaces. Cluster metadata: version, endpoint exposure settings, node-pool configuration and encryption settings.
Complium, EIC's compliance management platform, collects the cloud-account layer through read-only integrations: on Azure, Microsoft Entra ID, Activity Logs and Microsoft Defender for Cloud, whose recommendations include AKS; on AWS, IAM, CloudTrail, Security Hub and Config, which include EKS-related controls. The cluster-level artefacts above are exported from the cluster and uploaded as evidence, where the same engine maps them to PCI DSS v4.0.1 requirements and flags what is missing. For Google Cloud and Alibaba Cloud environments the account layer is also handled through exported evidence today; native read-only connectors for both are on the roadmap.
What read-only means: Complium's Azure and AWS integrations request read permissions only. They cannot modify a cluster, a role or a policy, and access is scoped, auditable and revocable in Entra ID or IAM at any time.
Frequently Asked Questions
Is Kubernetes in scope for PCI DSS?
Yes, whenever pods that store, process or transmit cardholder data run on it. The cluster control plane, the nodes, every workload that shares the cluster network without enforced segmentation, the container registry, the CI/CD pipeline that deploys to the cluster, and every identity with API access to CDE namespaces are in scope. A Kubernetes namespace on its own is a logical grouping, not a segmentation control, so it does not reduce scope by itself.
Does using managed Kubernetes (EKS, AKS, GKE or ACK) make my cluster PCI DSS compliant?
No. The provider operates and secures the control plane (API server, etcd, scheduler) and that portion is covered by its Attestation of Compliance. You remain responsible for worker nodes, workloads, container images, RBAC, network policy, secrets, logging configuration and admission controls. The provider's responsibility matrix will show the control plane as inherited and everything above it as yours.
Can I run PCI and non-PCI workloads in the same Kubernetes cluster?
You can, but the whole cluster is then in scope unless you implement and test hard multi-tenancy: enforced NetworkPolicy or service-mesh authorization policies between namespaces, separate node pools with taints and tolerations, distinct RBAC bindings, and separate secrets and registries. Your QSA will treat the isolation as a segmentation control and it must be penetration-tested under Requirement 11.4.5. Many organisations find a dedicated CDE cluster is cheaper to assess than proving hard multi-tenancy.
Does Kubernetes NetworkPolicy count as network segmentation for PCI DSS?
It can, provided the cluster runs a CNI that actually enforces NetworkPolicy (Calico, Cilium, Azure CNI with policy, GKE Dataplane V2, Terway on ACK) and the policies default to deny with explicit ingress and egress allow rules. Policy objects that exist in a cluster whose CNI ignores them provide no segmentation at all. Whichever mechanism you use, the segmentation must be tested at least every 12 months, or every six months for service providers.
Does container image scanning satisfy PCI DSS Requirement 11.3 vulnerability scans?
No. Image scanning addresses Requirement 6 (secure systems and software) by finding known vulnerabilities before deployment. Requirement 11.3 still requires quarterly internal vulnerability scans of the running environment and quarterly external scans by an Approved Scanning Vendor against internet-facing addresses, including ingress load balancers and node public IPs. You need both.
How does Complium collect PCI DSS evidence for a Kubernetes environment?
Complium's read-only integrations cover the cloud-account layer: on Azure, Microsoft Entra ID, Activity Logs and Defender for Cloud (which includes AKS recommendations); on AWS, IAM, CloudTrail, Security Hub and Config (which include EKS-related findings). Cluster-level artefacts such as RBAC bindings, NetworkPolicy manifests, admission policies, audit-log configuration and image scan reports are exported from the cluster and uploaded as evidence, where the same engine maps them to PCI DSS v4.0.1 requirements. There is no native GCP or Alibaba Cloud connector yet; both are on the roadmap.
For the provider-level picture across all four clouds, see PCI DSS in the Cloud: AWS, Azure, GCP and Alibaba Cloud compared. For the standard itself, our complete PCI DSS guide covers all twelve requirements in depth.