Which PCI DSS requirements can Kubernetes policy enforce?
Kubernetes policy can enforce the PCI DSS v4.0.1 requirements that describe workload configuration, such as privileged containers, host access, RBAC wildcards, Secret exposure and image sources. It can produce evidence for inventory. It cannot enforce identity, audit-log retention, anti-malware or PCI scope, because those are process or infrastructure controls.
Which version this maps to, and where the text came from
This mapping targets PCI DSS v4.0.1. The PCI Security Standards Council PDF returned HTTP 403 to our fetches, so the requirement wording here comes from a public mirror of that PDF. We checked the requirement numbers and statements against the mirror. Confirm the wording against the official PCI SSC copy before you quote it to an assessor.
The three-column view
The table sorts the requirements by what a policy can do with them. The mapping is ours, and each row groups several requirement numbers.
| Policy can enforce | Policy can support with evidence | Policy can’t touch |
|---|---|---|
| 2.2.4: block host ports, NodePort and LoadBalancer Services | 2.2.1: policies serve as the configuration standard’s enforced checks | 2.2.7 and 8.3.1: admin access encryption and authentication |
| 2.2.4, 7.2.5: privileged, host namespace, hostPath and capability limits | 6.3.2: policy reports list what each resource was checked against | 8.2.1, 8.2.2, 8.6.1: unique IDs, shared IDs and interactive system accounts |
| 7.2.1, 7.2.2, 7.2.5: Secret access by name, Secret env vars, token automount, RBAC wildcards | 6.3.3: stale-image checks are a proxy for patch currency, not patch status | 3.5.1: PAN stored unreadable |
| Approved registries, digests and Cosign signatures for images (feeds the 6.3.2 evidence) | 10.2.1: Kyverno’s own admission results, not API server audit logs | 5.2.1, 5.3.1: node anti-malware and updates |
| 4.2.1: HTTPS-only Ingress (not cipher strength) | 1.2.1: NetworkPolicy shape checks against NSC rulesets | 6.2.4, 6.5.1: secure coding and change approval |
| None directly | None directly | 10.2.1.1, 10.3.2, 10.4.1, 10.5.1: audit log scope, protection, daily review and 12-month retention |
| None directly | None directly | 11.3.1, 11.5.1, 11.6.1, 12.5.2: scans, intrusion detection, payment page tamper checks and scope |
Requirements policy can enforce
Privileged and host access
Kyverno’s sample policies in the Pod Security Standards (Baseline) category block privileged containers, host namespaces, hostPath volumes, host ports and added capabilities. The Restricted category adds rules such as disallowing privilege escalation and requiring non-root users. Kubernetes defines the Privileged, Baseline and Restricted profiles these categories follow. The policies are general pod hardening, not PCI-specific controls.
Map these to 2.2.4, which asks that only necessary services, protocols and functions are enabled, and to 7.2.5, which covers least privilege for system and application accounts. Neither requirement names a privileged flag, so state the mapping in your report.
Secrets, service accounts and RBAC
Four policies narrow access to credentials and permissions. restrict-secrets-by-name limits which Secrets a workload can reference. disallow-secrets-from-env-vars blocks Secrets as environment variables, which the policy text says can end up in log output. restrict-sa-automount-sa-token stops ServiceAccount tokens from mounting by default. restrict-wildcard-verbs blocks Roles and ClusterRoles with a wildcard verb.
Kubernetes’ RBAC good practices say to avoid wildcard permissions where possible, because a wildcard also covers resource types added later. The policy enforces that at the point a role is written. These controls support 7.2.1 and 7.2.2 (access by job function and least privilege). They do not replace an access review, so the approval record still lives outside the cluster.
Images and supply chain
Three policies control where images come from. restrict-image-registries allows only the registries you list. require-image-checksum requires digests rather than mutable tags. verify-image checks a Cosign signature; the sample verifies a named test image, and you point it at your own signed images. Together they limit which third-party components can run. They do not give you the full inventory that 6.3.2 asks for, which is why that row sits in the evidence column.
Ingress and exposure
require-ingress-https requires that each Ingress disables HTTP and specifies TLS. That supports 4.2.1, which covers strong cryptography for PAN sent over open networks, but only at the Ingress. It says nothing about cipher suites or certificate trust, so 4.2.1 stays partly open. restrict-networkpolicy-empty-podselector checks NetworkPolicy shape, which helps with 1.2.1 network security control rulesets. restrict-node-port and restrict-loadbalancer limit exposed Services. The NodePort policy text notes that a NetworkPolicy cannot control traffic to host ports, so this policy is the control.
Requirements that need evidence, not enforcement
Kyverno records its results in policy reports, which the docs describe as Kubernetes custom resources generated and managed automatically. Use them as evidence that a control ran against each resource. They show what passed and failed in the admission path. They don’t show that a control existed outside Kubernetes.
Three rows of the table depend on that evidence. For 6.3.2 (software inventory), the reports list what each resource was checked against, but they are not a complete bill of materials. For 2.2.1 (configuration standards), a policy is a machine-checked version of a standard, and the reports show it applied. For 6.3.3 (critical patches within a month), block-stale-images inspects image contents and flags old images, which is a proxy. It shows that an image is old, not whether a given CVE has been patched.
Requirements policy can’t touch
Admission policies see resource objects. They do not see the node’s operating system, the identity provider, the log platform or the payment page. Requirement 8 (identification and authentication) sits in the identity provider. Requirement 10 (logging and monitoring) depends on API server audit configuration, a log store with protected retention and a daily review process. Requirement 5 (anti-malware) needs an agent on each node. Requirement 11 needs scanners and intrusion detection, and 12.5.2 needs a documented scope. None of these is a field on a Kubernetes object.
A checklist for mapping your scope
- Confirm the version (v4.0.1) and list the clusters that store, process or transmit cardholder data, then document the scope boundary.
- For each in-scope requirement, label it enforce, evidence or out of reach, using the table above.
- Enforce only requirements that a resource field expresses, such as privileged flags, image sources, RBAC verbs and Secret references.
- Run the policies without blocking, read the policy reports, and fix the findings before you turn on enforcement.
- Record each out-of-reach control with its owner, tool and evidence location, so the assessor sees who owns it.
Enforcing this with Kyverno
Kyverno’s policy library has the sample policies this post cites. Each policy page lists its category and the Kyverno version it targets; the pages we checked were on v1.19.0. Start with the Baseline and Restricted pod policies, then add the Secret, RBAC and image policies that match the requirements in your scope. Keep the policy reports as evidence and note the requirements each one supports.
For the wider program, the continuous compliance hub covers how Kyverno policy, evidence and audits fit together. Payment teams can compare the approach in how Razorpay automates RBI compliance on Kubernetes with Kyverno, and how Chase UK made Kubernetes audit-ready with Kyverno shows the same evidence model from an adopter’s side. For the policy-to-control approach behind a regulated framework, read automating NIS2 compliance in Kubernetes with Kyverno. If you want Kyverno packaged for enterprise use, see Nirmata Enterprise for Kyverno.
Frequently asked questions
Does PCI DSS v4.0.1 let you satisfy a requirement with a Kubernetes policy?
Only for requirements that describe a configuration you can express as a resource field, such as privileged: true, a hostPath volume or an image registry. Most PCI DSS requirements are about processes, people, logs and scope. A policy can enforce the configuration part of those requirements and give evidence for the rest, but an assessor still needs the process controls documented.
Which PCI DSS requirements do Kyverno's sample policies map to?
The mapping in this post is ours, not the PCI Security Standards Council's. We matched each Kyverno policy's behavior to a requirement's wording. Treat it as a starting point and confirm each row with your QSA before you rely on it in a report.
Can a Kyverno policy show auditors that logging is enabled?
Not for the cluster's audit logs. Kyverno writes its own admission results to policy reports, which are Kubernetes custom resources. Requirement 10 asks for audit logs of system components, including API server audit logging, retention for at least 12 months and daily review. Those come from the cluster and the log platform, not from an admission policy.
Should we block violations or only report them at first?
Read the policy reports first. Each report lists the results per resource, so you can see which workloads would fail before a policy blocks them. Fix the findings, then move the policy to enforcement. The same reports serve as evidence for the requirements that policy supports but does not block.