PCI DSS in containerised environments

Updated: 4 July 2026

What are containerised environments in the context of PCI DSS? Containerisation (Docker, Kubernetes, OpenShift) is a technology that isolates applications in lightweight, portable execution units. In the context of PCI DSS, containerised environments are treated like any other IT infrastructure – if containers store, process, or transmit cardholder data (CHD), they fall within the certification scope. PCI DSS v4.0.1 does not contain a separate set of requirements for containers – the same 12 requirement areas apply, but their interpretation and technical implementation are specific to the containerised architecture. Misunderstanding this specificity leads to the most common audit surprises.

PCI DSS in containerised environments – at a glance:

Containers that store, process, or transmit CHD fall within PCI DSS scope – in the same way as virtual machines and physical servers
The orchestrator (Kubernetes cluster, OpenShift) managing CDE containers falls within scope as a connected-to system
Container images used by CDE systems must be scanned for vulnerabilities (PCI DSS v4.0.1 Requirement 6.3.3)
Network segmentation between Kubernetes namespaces must be technically verifiable and documented – Kubernetes Network Policies or a service mesh
The ephemeral nature of containers creates challenges for logging and monitoring (Requirement 10) – logs must be exported to an external SIEM before a container is terminated
Patronusec as an accredited QSA delivers PCI DSS assessments for hybrid environments (cloud plus containers) and supports preparation of Kubernetes scope documentation

How do you determine the PCI DSS scope (CDE) in a Kubernetes environment?

Establishing the CDE scope in a Kubernetes environment is more complex than in a traditional architecture because network boundaries are dynamic and containers can be rescheduled between nodes.

What falls within PCI DSS scope in a Kubernetes environment:

Pods and containers processing CHD – directly in scope
Kubernetes namespaces containing CDE pods
Kubernetes control plane (API server, etcd, scheduler, controller manager) – connected-to, because it manages CDE pods
Worker nodes running CDE pods
Container registries storing images used by CDE pods
CI/CD pipelines deploying changes to the CDE environment

What may be out of scope (with correct segmentation):

Kubernetes namespaces isolated from CDE namespaces by Network Policies
Worker nodes that never run CDE pods (enforced by taints and tolerations)
Shared infrastructure with correct segmentation (load balancers, monitoring) – depends on configuration

Common scope traps in Kubernetes:

Shared etcd – Kubernetes etcd stores the state of the entire cluster, including secrets and configurations. If etcd is shared between CDE and non-CDE namespaces, the entire shared cluster is potentially in scope. Recommendation: a dedicated Kubernetes cluster for the CDE, or etcd encryption.

Shared ingress controller – if the ingress controller serves traffic to both CDE and non-CDE services, it is connected-to and falls within scope. Recommendation: a dedicated ingress for the CDE or L4-level separation.

Patronusec Insight: The most common trap in PCI DSS assessments of Kubernetes environments is treating a namespace as a security boundary without QSA verification. A Kubernetes namespace is an administrative boundary, not a network boundary. Without explicit Network Policies, pods in different namespaces can communicate freely – which means a non-CDE namespace is connected-to the CDE and falls within scope. Verifying Kubernetes segmentation is one of the first steps in our scope assessment for containerised environments. See our PCI DSS certification offering.

What are the PCI DSS v4.0.1 requirements for container image security?

PCI DSS v4.0.1 does not explicitly name “container images” in the standard text, but several requirements apply directly.

Requirement 6.3.3 – Vulnerability management in software components:

All software components must be protected against known vulnerabilities – which includes base images and container dependencies. In practice, this means:

Scanning container images for CVEs before deployment (SAST for images: Trivy, Grype, Snyk Container)
Regular scanning of deployed images (new CVEs may emerge after a build)
A policy on acceptable vulnerabilities (for example, automatically blocking Critical/High CVEs in the CI/CD pipeline)
Updating base images and dependencies on a regular cycle

Requirement 2.2.1 – Secure configurations:

Containers must be securely configured from the point of build. Good practices:

Non-root user in Dockerfile
Read-only filesystem where possible
Minimal base image (distroless or alpine rather than a full OS)
No credentials hardcoded in Dockerfile or plaintext environment variables (use a secrets manager: Vault, AWS Secrets Manager, Kubernetes Secrets with encryption at rest)

Requirement 6.2.4 – Security of bespoke and custom-developed code:

For organisations writing their own applications deployed in containers – code review, SAST, and DAST requirements apply to application code, not only to the base image.

Requirement	Kubernetes implementation	Tooling
Image scanning (6.3.3)	In CI/CD pipeline before push to registry	Trivy, Snyk, Grype
Secure configuration (2.2.1)	PodSecurityStandards, SecurityContext	OPA/Gatekeeper, Kyverno
Network segmentation	Kubernetes Network Policies	Calico, Cilium
Secrets management	External Secrets Operator	Vault, AWS SM, Azure KV
Logging (10.x)	Sidecar or DaemonSet log shipper	Fluentd, Filebeat

Do you have a Kubernetes environment with components processing cardholder data and are planning PCI DSS certification?

For PCI DSS in containerised environments, Patronusec conducts scope assessments that map CDE and connected-to systems and identify documentation requirements specific to Kubernetes.

Book a scope assessment for containerised environments

How do you satisfy PCI DSS Requirement 10 logging obligations in ephemeral container environments?

The ephemeral nature of containers (short lifespans, automatic restarts) creates specific challenges for PCI DSS logging requirements.

The logging problem in containers:

Containers write logs locally to stdout/stderr by default. When a container is deleted or restarted, those logs are lost. PCI DSS v4.0.1 Requirement 10.5.1 mandates log retention for 12 months with the most recent 3 months immediately available online. Local container storage does not satisfy this requirement.

The solution – centralising logs before container deletion:

Every log must be exported to an external SIEM or log aggregator before the container is deleted. Common architectures:

Sidecar pattern: a dedicated container in each pod collects and forwards logs to the SIEM
DaemonSet log shipper: an agent on each node collects logs from all containers on that node
Log aggregator: Fluentd/Fluent Bit (as a DaemonSet) forwarding to Elasticsearch or an external SIEM

What must be logged (Requirement 10.2):

In a Kubernetes environment, additional logging is required for:

Kubernetes API server audit logs (configuration changes, secret access)
Container registry logs (image pull and push events)
CI/CD pipeline logs (deployments to CDE environments)
Node-level logs (system and kernel events)

Patronusec Insight: Organisations migrating from traditional infrastructure to Kubernetes often assume their existing log management solution (SIEM, syslog) will automatically handle container logs. In practice, integration is required – Kubernetes does not forward logs automatically to traditional syslog collectors. Absent or incomplete log configuration in a Kubernetes environment is one of the most common findings in our QSA assessments of containerised environments. We help clients design a logging architecture that a QSA will accept, as part of our PCI DSS gap analysis service.

How does network segmentation work in Kubernetes – and how do you document it for a QSA?

Network segmentation in Kubernetes differs fundamentally from segmentation in traditional infrastructure (L3 firewalls, VLANs). A QSA must understand how Kubernetes Network Policies work in order to assess whether segmentation is effective.

Kubernetes Network Policies – how they work:

Network Policies are L3/L4 rules defining which pods may communicate with which other pods or external IPs. They require a CNI (Container Network Interface) that supports Network Policy enforcement – the default CNI in many distributions (for example, Flannel) does not enforce Network Policies. Required CNIs: Calico, Cilium, Weave Net, or equivalent.

Segmentation documentation for a QSA:

The QSA needs to see:

A list of all Network Policies applied to CDE namespaces
Confirmation that the CNI enforces Network Policies (not merely defines them)
Segmentation test results (attempts to connect from non-CDE to CDE should be blocked)
A network diagram showing traffic flows with the CDE and segmentation boundaries clearly marked

Segmentation testing in Kubernetes:

PCI DSS v4.0.1 Requirement 11.4.4 mandates segmentation testing at least annually. In a Kubernetes environment, the test involves attempting to establish connections between pods in different namespaces and verifying that Network Policies block unauthorised traffic.

FAQ – PCI DSS in containerised environments

Do I need a separate Kubernetes cluster for the CDE?

Not a strict requirement – it is possible to certify a CDE environment within a shared Kubernetes cluster with correct segmentation. However, a shared cluster expands the certification scope (control plane, etcd, and shared nodes become connected-to) and requires more rigorous documentation. A dedicated CDE cluster is often the simpler and more cost-effective long-term solution.

Are Kubernetes API server logs required by PCI DSS?

Yes – the Kubernetes API server is the system governing access to the CDE environment. API server audit logs – particularly configuration changes, secret access, and deployments – are required by Requirement 10.2 as logs covering privileged access and configuration changes.

How often must container images be scanned for PCI DSS?

PCI DSS v4.0.1 Requirement 6.3.3 requires scanning “at least once every 12 months” and “after any significant change.” In a CI/CD environment, scanning at every build and before every production deployment is both more secure and easier to document for a QSA.

Do Helm charts and Kubernetes manifests need to be reviewed for PCI DSS?

Yes – Helm charts and Kubernetes manifests define the security configuration of pods (SecurityContext, resource limits, Network Policies). Reviewing these documents is part of the security configuration assessment (Requirement 2.2.1) and change management (Requirements 6.4.x). A QSA may request manifests for CDE namespaces.

How much does a PCI DSS assessment for a Kubernetes environment cost with Patronusec?

Cost depends on the CDE scope within the Kubernetes environment, the number of clusters, the cloud model (managed Kubernetes versus self-hosted), the number of applications, and the complexity of segmentation. Patronusec provides a fixed-price quotation after a free call and scope assessment. Kubernetes environments typically require more time for scope assessment than traditional infrastructure.

Does PCI DSS certification for Kubernetes environments differ from a standard assessment?

The certification standard is the same – the same 12 requirement areas, the same documents (ROC or SAQ). What differs is the implementation of controls and the documentation. A QSA must understand Kubernetes specifics – not every QSA has hands-on container experience. When selecting a QSA, ask specifically about previous projects in Kubernetes or Docker environments.

PCI DSS certification for containerised environments – free consultation

Patronusec as an accredited QSA delivers PCI DSS certifications for hybrid and cloud-native environments – including Kubernetes, Docker, and OpenShift. Our team combines QSA expertise with DevSecOps knowledge.

In a free 30-minute consultation we will help you:

Provide an initial assessment of the CDE scope in your Kubernetes environment and identify connected-to systems
Discuss documentation requirements specific to containerised environments
Plan the scope assessment and certification timeline
Recommend segmentation and logging architectures acceptable to a QSA

Free consultation | PCI DSS certification | Gap analysis PCI DSS | Penetration testing | vCISO

Blog space

PCI DSS in Kubernetes and Container Environments – Requirements and Best Practices

Inside this article:

Table of Contents