PCI compliance in container and Kubernetes environments

The Payment Card Industry Data Security Standard (PCI DSS) was created in 2004 by Visa, MasterCard, American Express, Discover, and JCP to create an industry-wide standard for security and data protection. The standards have been updated many times since they were first released to keep up with changes in technology. The standards apply to everything in the cardholder data environment, which is the people, processes, and technologies that store, process, or transmit cardholder data. In terms of technology, this includes both hardware and software.

Complying with PCI requirements isn’t easy, and costs an average of $5.5 million annually for companies. However, non-compliance is much more expensive, with an average annual cost from penalties of $14.8 million. With the right processes and tools in place, PCI compliance doesn’t have to be a major challenge.

PCI DSS has 12 requirements that are mapped to six more general goals. They are:

Build and maintain a secure network system

  1. Install and maintain a firewall configuration to protect cardholder data
  2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect cardholder data

  1. Protect stored cardholder data
  2. Encrypt transmission of cardholder data across open, public networks

Ensure the maintenance of vulnerability management programs

  1. Protect all systems against malware and exploits, and regularly update anti-virus software
  2. Develop and maintain secure systems and applications

Implement strong access control measure

  1. Restrict access to cardholder data by business based on need-to-know
  2. Identify and authenticate access to system components
  3. Restrict physical access to cardholder data

Regularly monitor and test networks

  1. Track and monitor all access to network resources and cardholder data
  2. Regularly test security systems and processes

Ensure the maintenance of information security policies

  1. Maintain a policy that addresses information security for all personnel

PCI compliance for containerized applications

There are several requirements pertaining to each of the above six goals outlined by PCI that are directly relevant to container and Kubernetes environments. Evaluate your container and Kubernetes security tooling to ensure they can address these requirements:


Current network diagram that identifies all connections between the cardholder data

environment (CDE) and other networks, including any wireless networks


Requirements for a firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.


Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.


Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment and specifically deny all other traffic.


Limit inbound Internet traffic to IP addresses within the DMZ.


Do not allow unauthorized outbound traffic from the cardholder data environment to the internet.


Permit only “established” connections into the network.


Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.


Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry- accepted system hardening standards.


Implement only one primary function per server to prevent functions that require different security levels from coexisting on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)


Enable only necessary services, protocols, daemons, etc., as required for the function of the system.


Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.


Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.


Encrypt all non-console administrative access using strong cryptography.


Maintain an inventory of system components that are in scope for PCI DSS.


Secure cryptographic key distribution.


Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.


Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.


Separate development/test environments from production environments and enforce the separation with access tools.


Separation of duties between development/test and production environments.


Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.


Insecure cryptographic storage.


Insecure communications.


All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1).


Implement automated audit trails for all system components to reconstruct use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges.


Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify that all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel.


Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.


Implement a process to respond to any alerts generated by the change-detection solution.

Last updated: May-30-2020