In Part 1, we highlighted several key security frameworks and guidelines to achieve a baseline because they supply more granular information and real-world applications for achieving Kubernetes compliance. Now, we’re going to look at industry standards.

Falling back on our nautical similes, industry standards are like a ship’s captain overseeing their ship. When a captain wants to leave port, they will reel off an order to set sail. They have an expectation of what actions are involved and how they should be achieved, but the captain leaves it to experienced hands to implement how the process is done, although they may check from time to time that they are doing it correctly and safely.

The experts setting the sails are like the security guidelines and frameworks we have, such as NIST and the CIS. They know what ropes to pull, the best ways to get the ship out of the port, and the potential threats, and they know how to meet their captain’s exacting standards. 

In Part 2:
PCI DSS Kubernetes Compliance
Auditing and Assessment Challenges
SaaS Provider Risks
Networking Challenges
Business as Usual
PCI DSS: The Cost of Non-Compliance
PCI SSC Cloud Computing Guidelines
Guidance for Containers and Container Orchestration Tools

What your organization’s K8s platform will need to comply with will greatly depend on the industry in which your organization operates. If a company's stocks are publicly traded in the United States, it must comply with the SOX regulations, while financial companies come under the Gramm–Leach–Bliley Act (GLBA). Those organizations in the energy sector must adhere to North American Electric Reliability Corporation (NERC), Federal Energy Regulatory Commission (FERC), or Critical Infrastructure Protection (CIP) standards. If you operate in the healthcare industry, you must follow the HIPAA standards, which are incorporated into legislation focused on electronic health records.

Each industry standard’s framework has unique demands, and their requirements can differ. For example, the HIPAA standard only strongly recommends data loss prevention tools in its framework, while GDPR (the EU’s data protection law), PCI DSS, and SOC 2 (the security framework developed by the American Institute of Certified Public Accountants for protecting customer data) explicitly require it along with a web application firewall. No organization would operate without data loss prevention in place, but it does highlight the disparity between industry standards.

Industry standards such as PCI DSS provide use cases, best practices, and threats that need to be interpreted for Kubernetes.
Photo by Nathana Rebouças on Unsplash

PCI DSS Kubernetes Compliance

Unfortunately, how to achieve compliance for K8s within an industry-standard framework isn’t always that clear. Sometimes, standards are slow to respond and evolve with emerging new technologies. We’ll provide some pointers for PCI DSS, as it is a good example of this. 

The Payment Card Industry Data Security Standard (PCI DSS - PDF) is an industry standard that plods slowly forward, even though it is the global standard for ensuring a secure environment for payment card information. Any organization accepting, processing, storing, and transmitting debit and credit card data must comply with PCI DSS.

Bearing in mind that PCI DSS was created to detail the baseline technical and operational requirements for protecting account data, it wasn’t until March 2022, with the release of v.4, that we saw the cloud directly mentioned in the standard itself. Later, in September 2022, the Best Practices for Container Orchestration Special Interest Group published a more relevant supplement, Guidance for Containers and Container Orchestration Tools - PDF. 

Prior to that, anyone dealing with Kubernetes PCI compliance had to refer to the supplementary PCI SSC Cloud Computing supplementary guide - PDF (discussed below), published in 2013 and updated in 2018, as it specifically covered container security in section E7. (Note: There was an earlier supplementary Cloud Computing guide in 2013, but as Kubernetes was released in 2015, it only mentioned ‘containers’ once and in relation to VMs.)

Auditing and Assessment Challenges

As mentioned, one of the main goals of compliance is enabling correct, regular auditing and assessments. However, people who carry clipboards and are concerned with checking boxes aren’t interested in the fact that the technology your organization uses is ephemeral. 

A PCI DSS assessment requires an inventory of cloud resources, activity records, and logs for all your Kubernetes clusters within the scope of PCI DSS, regardless of when or how long they existed. Assessors also expect to see details of any custom scripts or internal software an organization uses to support payments.

A number of different Kubernetes components create logs, such as the K8s API server, etcd, kubelet, proxy and scheduler, and their logs are stored in /var/log. But many logs do not persist. For example, when a pod is deleted from a node, kubelet deletes all relevant logs, 

PCI DSS v4.0 itself recommends adding automation to circumvent this problem using a centralized logging and monitoring system. A common approach is running an EFK stack, where the ‘F’ stands for Fluentd, which collects and aggregates raw data from your K8s cluster and applications, and Elasticsearch stores the data. The ‘K’ refers to Kibana, a data visualization and exploration tool that will visualize the metrics and logs stored in Elasticsearch.

SaaS Provider Risks

PCI DSS v4l also highlights the need to consider the risks involved in using SaaS providers, as they are classed as Third-Party Service Providers (TPSPs), and their PSI DSS compliance requirements affect you as a customer (in Section 12.8). PSI DSS makes it clear that an organization is “wholly responsible for the actions of your service provider.”

Networking Challenges

Most K8s clusters are connected to at least one network, and an understanding of how system components are connected is crucial. When handling cardholder data, isolation and separation are critical, and your K8s cluster should not share networking infrastructure with other clusters or unnecessary external processes. The requirements specified in PCI DSS for networking are defined in Requirement 1, p46:

• Processes and mechanisms for installing and maintaining network security controls are defined and understood.
• Network security controls (NSCs, such as firewalls and any security technology that acts as a network policy enforcement point) are configured and maintained.
• Network access to and from the cardholder data environment is restricted.
• Network connections between trusted and untrusted networks are controlled.
• Risks to the Cardholder Data Environment (CDE) from computing devices that can connect to both untrusted networks and the CDE are mitigated.

Note: The CDE is defined as “system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication data,” as well as system components that aren’t used for storing, processing, or transmitting cardholder or sensitive data, but have unrestricted to components that do.

Business as Usual

This version also provides general guidance on Business As Usual (BAU) measures in section 5, which is general enough to cover any architecture, whether cloud-native and Kubernetes or not and requires that an organization “ensure that security controls that have been implemented to secure data and an environment continue to be implemented correctly and functioning properly as normal course of business.“ This section also covers additional “processes to detect anomalies, and alert and report so that responsible individuals address the situation in a timely manner.” However, there is nothing here that we would not expect to be part of an organization's overall security strategy already.

PCI DSS: The Cost of Non-Compliance

When sensitive financial data is involved,  there are always severe consequences for non-compliance. In this case, it is banks and payment processors, not the PCI DSS Council itself, that hand out hefty fines for PCI DSS non-compliance. These usually involve $50-$90 fines per customer for data breaches. Fines are also charged by the month for non-compliance, starting at $5,000-$10,000, depending on the volume, and they rise to $50,000 to $100,000 a month after seven months. The actual cost to an organization depends on the contract signed with the payment processor. 

Sadly, it doesn’t end there; organizations need to consider loss of earnings, potential legal settlements, and damage to reputation. For example, when Target lost the credit and debit card information of 40 million customers in 2013, The New York Times reported that the retail corporation paid out almost $18.5 million in legal settlements across 47 states and spent more than $202 million in legal fees and other costs.

Non-compliance is costly, so avoiding the potential security risks and financial and reputation damage that come with running a non-compliant Kubernetes platform requires careful planning.

Prior to the release of PCI DSS v4 in 2022, organizations had to refer to a supplementary Cloud Computing document for guidance.

PCI SSC Cloud Computing Guidelines

There are over 60 documents and supplements covering specific guidance supplied by the PCI Security Standards Council, although the most relevant is the PCI SSC Cloud Computing Guidelines. Section 5 of the guide lists many examples of the challenges but readily admits that “distributed architectures of cloud environments add layers of technology and complexity that challenge traditional assessment methods.” Examples include difficulty in collecting, correlating, and archiving all the logs for PCI DSS compliance, the lack of visibility into a provider's underlying infrastructure and their security controls, and identifying who is responsible for particular PCI DSS controls.

Being an older supplement, Cloud Computing focuses on controls for image templates and container “groups” or clusters. Its main concern is segmenting any environment that stores and processes customer debit and credit card data.

The bare minimum guidelines, which are still relevant now, are:

1. Access Controls - ensure different workloads do not have access to identity tokens, keys, and other confidential data used by other containers in a cluster by controlling the orchestration framework and the containers.
   
   
2. Process Isolation - ensure running containers are isolated based on kernel namespaces and CGroups and also use controls to enforce kernel permission checks on privileged processes.
   
   
3. Access Restriction - ensure restricted access for containers to host filesystems and container filesystems by other containers.
   
   
4. Syscall Firewall - ensure the firewall is container-specific. The guidance recommends kernel security features such as AppArmor, SELinux, RSEC, and Secure Computing Mode (seccomp) for preventing unsafe syscalls.
   
   
5. Network and Admin Isolation - ensure strong isolation between containers hosting different workloads based on a container-specific network interface such as the docker0 interface and Software Defined Networking (detailed in Section E.4).
   
   
6. Kernel Isolation - ensure that kernel isolation complies with the recommendations in the PCI DSS Virtualization Guideline for mixed-mode workloads.
   
   
7. Access Auditing - ensure that an audit of access approvals can be generated for Kubernetes to demonstrate least privilege access has been applied to only appropriate people for the in-scope workloads.
   
   
8. CI/CD Control Validation - the integrity of the CI/CD pipeline and change control has to be
   evaluated to validate the strength of the controls.
   
   
9. Image Repository - ensure secure management and creation of images in the image repository under strict change management.
   
   
10. Image Integrity - ensure that container images are patched during the process of image creation and that images undergo standard vulnerability assessment before being committed to the repository.
    
    
11. Read-Only Containers - where supported by the application.

The guidelines also specify that an organization needs to carefully assess the Kubernetes solution provider that it selects to ensure it can provide the following:

• Fully isolated containers.
• If isolation isn’t assured, then workload deployments into discrete workload-specific clusters.
• Where workloads are deployed into shared workload clusters, the guidelines suggest ensuring isolation by using individual customer accounts that are workload-specific.

As a matter of principle, the supplement recommends using open-source or commercial off-the-shelf solutions rather than building in-house container technology and ensuring that proper due diligence is carried out.

Additionally, to manage the fact that containers are often destroyed and retired and handle the challenge of implementing security controls, the guidelines advise sampling running instances across all in-scope container images. In this way, organizations can address PCI DSS’ quarterly and annual reporting demands and comply with the file integrity monitoring and pen testing requirements.

Guidance for Containers and Container Orchestration Tools

The most recent guidance document contains specifics on how to deal with a number of common implementations that you may face. The 44-page supplement, published in 2022, applies best practices developed by industry experts and as well as providing an overview of containers and container orchestration. In Section 3, the guidance covers:

• Potential threats to containers and container orchestration tools in a payment system. 
• Security best practices for handling the threats posed to payment systems.
• Use case examples of threats and the best practices to address those threats. 

Threats and best practices are listed in a handy table on p19 and highlight areas of concern, such as authentication and authorization, workload security, network security, Public Key Infrastructure (PKI), Secrets management, auditing container orchestration tools, container monitoring, container runtime security, patching, resource management, container image building, registry, version, and config management.

We have mentioned NIST and a few other security frameworks along with one industry standard so far in this Kubernetes compliance series. In Part 3, we provide a high-level overview of some open-source policy and governance tools within the K8s ecosystem that are used to automate Kubernetes compliance and streamline the process. 

Contact Us

Need help with K8s compliance? Take the pain out of the process and connect with us today to discover how we can reduce workloads and support and work with your teams.

CONNECT WITH US