Kubernetes for PCI DSS segmentation and logging

Requirement 10.2.1 expects audit logs to be enabled and active for all system components and cardholder data, and requirement 10.2.2 defines what each entry must record: event type, date and time, success or failure, origination, and the identity of the affected data, component, resource or service. In a Kubernetes cluster, the kube-apiserver is the most useful point to satisfy this, because every create, read, update, patch and delete request to the API passes through it. The API server only writes audit events when an audit policy and a log backend are configured, so the first task is to confirm which audit policy levels your chosen distribution ships with and which fields it actually writes. Node and container runtime logs are a separate question and need their own mapping.

The origination field depends on how each caller authenticates. Kubernetes supports X.509 client certificates, bearer tokens including OpenID Connect and JWT, webhook token authentication and authenticating proxies, and each method passes a different identity into the audit record. For OIDC, the username and group claims you configure determine what appears in the log, so confirm the claim mapping with your identity team before you rely on it. A shared admin certificate weakens this field badly, because every action is attributed to the same subject and an assessor cannot tie a change to a person. Inventory how administrators, CI pipelines and service accounts authenticate, and plan to retire shared certificates for daily operations.

Secrets need specific attention in the audit design. By default, Kubernetes stores Secrets unencrypted in etcd, so anyone who can read etcd data or its snapshots can read the values. Encryption at rest protects etcd and the backups taken from it, and it should be confirmed for the distribution you run. Least-privilege RBAC that restricts list and watch access matters just as much for logging, because a list request on Secrets returns full values through the API. Set the audit policy so that request and response bodies for Secrets are not written in plain form, and confirm that the policy still records who read or changed them. Where Secrets come from an external store, confirm that store's own audit trail as well.

The last decision is where the logs go. Audit records kept only on a control plane node are hard to protect and easy to lose when a node fails or is rebuilt. Confirm that the cluster forwards audit logs to a central store with retention and tamper protection that meets requirement 10.2 and the other logging requirements in the standard, and confirm the retention period with your assessor and your own policy rather than assuming a default. Test the chain end to end by making a change as a named user and locating the record in the central store. DeployOpen can prepare the configuration and the evidence for this, but the assessor decides whether the controls meet the standard.

A Kubernetes cluster can enforce network policies and produce API audit logs, but it does not make a payment environment compliant on its own. The platform does not define the cardholder data environment (CDE) or its scope. Under the PCI SSC glossary, the CDE covers the people, processes and system components that store, process or transmit cardholder data or sensitive authentication data, plus any component with unrestricted connectivity to them. The entity must draw that boundary from its own network and data-flow diagrams under Requirement 1.2. Kubernetes also does not decide which entity must validate. The payment brands make that decision, and the PCI SSC does not enforce compliance. Finally, the platform does not issue a Report on Compliance or an Attestation of Compliance. A Qualified Security Assessor produces the ROC, and the entity signs an AOC on the official template.

Most of the standard sits outside network controls and logging. Kubernetes gives no protection for cardholder data beyond what you configure. Secrets are stored unencrypted in etcd by default, so encryption at rest for Secrets must be enabled, but that is one control among many. The entity still owns encryption of cardholder data in databases, object storage and backups, vulnerability management, access reviews for people across identity providers and applications, incident response, and the other principal requirements in the twelve-requirement set. Platform engineers can supply evidence for some of these, such as RBAC bindings and audit records, but the control owners are the security, application, HR and operations teams that run those processes. Name an owner for each requirement in a gap register before the assessment starts.

Several scope questions need written answers from your QSA before you design the cluster. First, confirm whether the chosen CNI enforces the NetworkPolicy objects you plan to use as network security controls, because a policy the data plane does not enforce gives no segmentation evidence. Second, decide whether shared components fall in scope: ingress controllers, service meshes, node access paths and the kube-apiserver itself. Each of these can route or read cardholder traffic, or control the policies that define segmentation. Third, confirm how logs from nodes and from applications that write outside the API server are collected, retained and reviewed. Requirement 10.2.1 applies to all system components, so API audit logs alone may not cover the environment. Record each answer with the assessor's name and the date it was given.

Where a requirement cannot be met as written, PCI DSS v4.x offers two routes that teams often confuse. A compensating control is a different mechanism used when a defined requirement cannot be met for a documented, legitimate technical or business reason. A customized approach, available to entities with strong security and risk management, meets the stated objective of a requirement in a different way and is documented against that objective. Your assessor decides whether a customized approach applies to a given item and whether a proposed compensating control is acceptable, so raise both early. The items most likely to need one are the shared components and log sources listed above, if they cannot be enrolled in the design as planned.

Close each gap by assigning it to one owner. The platform or cluster team owns NetworkPolicy configuration, CNI selection, audit policy and the policy-as-code repository. Changes to these belong in the change control process defined in Requirement 6.5.1, as Requirement 1.2.2 expects. The security team owns the scope statement, the network and data-flow diagrams and the gap register. Application and data owners own encryption of cardholder data outside the cluster. The QSA validates the evidence and produces the ROC, while the payment brands and acquirer determine which validation applies to your entity. Ask your implementation partner for a written responsibility matrix that maps each sub-requirement to one owner, one piece of evidence and one review date before any cluster is built.

What drives effort and cost? The main drivers are the size of the cardholder data environment (CDE) and the number of clusters and namespaces inside it. Each namespace that hosts a cardholder data workload needs its own NetworkPolicy objects, Pod Security Admission labels, RBAC bindings and log routing, so a three-cluster estate with shared services in the CDE is a different job from one cluster with two namespaces. Other drivers are how mature your change control already is for network security controls under Requirement 1.2.2, whether policy changes move through reviewed Git commits or are applied by hand, and how far the logging pipeline must go to meet the retention and review expectations of Requirement 10. The QSA's stated evidence requirements also add scope, so ask for them early. Ask any provider to price these drivers separately in a written quote.

What does the work need from our side? Plan for named owners in four roles: a CDE owner who accepts scope decisions, a platform engineer with administrative access to the cluster, a repository owner who controls the policy-as-code repository and its branch protection, and a security or compliance lead who speaks to the QSA. Access must be concrete. The team needs read access to the API server audit policy, the ability to export current NetworkPolicy objects and namespace labels, and access to the Git history that serves as change approval. The QSA's written expectations should arrive before design starts, covering which samples they will take, how they will check the network and data-flow diagrams required under Requirement 1.2, and what they accept as evidence. Changes to those expectations late in the project usually mean rework, so record them in the scope document.

Can an internal team do this alone? Often yes, if the team already runs Kubernetes in production, owns a GitOps pipeline and has someone who has been through a PCI DSS assessment before. The gaps usually sit in the parts that are easy to skip: documenting which NSC rules support each approved service, port and protocol, keeping policy files under the same change control as application code, and proving that API audit logs capture the events listed under Requirement 10.2.1 with the fields described in Requirement 10.2.2. Teams without a recent assessment tend to underestimate evidence work. Decide early which parts you will staff internally and which you will hand to a partner, whether that is planning, build, or an independent review of the evidence pack, and write that split into the scope.

How long will it take? No supplied figure gives a reliable duration for this work, so do not rely on an estimate from us or anyone else until it appears in a written scope. A quote should state the phases, the environments covered, the deliverables, the dependencies on your QSA and change calendar, and what happens if the assessment date moves. Ask for the timeline split between design, build and evidence collection, along with the assumptions behind each part. Does DeployOpen certify the result? No. DeployOpen plans and builds the controls, prepares the configuration, documentation and evidence, and supports your team through the assessment. A Report on Compliance is completed by a Qualified Security Assessor, validation is documented on an Attestation of Compliance, and certificates are not recognized as validation. The payment brands decide which entities must validate.