PCI DSS compliance on GKE

Last reviewed 2023-10-31 UTC

This guide is intended to help you address concerns unique to Google Kubernetes Engine (GKE) applications when you are implementing customer responsibilities for Payment Card Industry Data Security Standard (PCI DSS) requirements.

Disclaimer: This guide is for informational purposes only. Google does not intend the information or recommendations in this guide to constitute legal or audit advice. Each customer is responsible for independently evaluating their own particular use of the services as appropriate to support its legal and compliance obligations.

Introduction to PCI DSS compliance and GKE

If you handle payment card data, you must secure it—whether it resides in an on-premises database or in the cloud. PCI DSS was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect credit card data. PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), or both.

Containerized applications have become popular recently with many legacy workloads migrating from a virtual machine (VM)–based architecture to a containerized one. Google Kubernetes Engine is a managed, production-ready environment for deploying containerized applications. It brings Google's latest innovations in developer productivity, resource efficiency, automated operations, and open source flexibility to accelerate your time to market.

Compliance is a shared responsibility in the cloud. Google Cloud, including GKE (both Autopilot and Standard modes of operation), adheres to PCI DSS requirements. We outline our responsibilities in our Shared responsibility matrix.

Intended audience

  • Customers who want to bring PCI-compliant workloads to Google Cloud that involve GKE.
  • Developers, security officers, compliance officers, IT administrators, and other employees who are responsible for implementing controls and ensuring compliance with PCI DSS requirements.

Before you begin

For the recommendations that follow, you potentially have to use the following:

  • Google Cloud Organization, Folder, and Project resources
  • Identity and Access Management (IAM)
  • Google Kubernetes Engine
  • Google Cloud VPCs
  • Google Cloud Armor
  • The Cloud Data Loss Prevention API (part of Sensitive Data Protection)
  • Identity-Aware Proxy (IAP)
  • Security Command Center

This guide is intended for those who are familiar with containers and GKE.

Scope

This guide identifies the following requirements from PCI DSS that are unique concerns for GKE and supplies guidance for meeting them. It is written against version 4.0 of the standard. This guide doesn't cover all the requirements in PCI DSS. The information provided in this guide might assist organizations in their pursuit of PCI DSS compliance but it's not comprehensive advice. Organizations can engage a PCI Qualified Security Assessor (QSA) for formal validation.

PCI DSS goals PCI DSS requirements
Segment your cardholder data environment Sometimes referred to as requirement 0. Alhough it's not a must for PCI compliance, we recommend this requirement to keep the PCI scope limited.
Build and maintain a secure network and systems 1. Install and maintain network security controls

2. Apply secure configurations to all system components
Protect account data 3. Protect stored account data

4. Protect cardholder data with strong cryptography during transmission over open, public networks
Maintain a vulnerability management program 5. Protect all systems and networks from malicious software

6. Develop and maintain secure systems and software
Implement strong access control measures 7. Restrict access to system components and cardholder data by business need to know

8. Identify and authenticate access to system components

9. Restrict physical access to cardholder data
Regularly monitor and test networks 10. Log and monitor all access to system components and cardholder data

11. Test security of systems and networks regularly
Maintain an information security policy 12. Support information security with organizational policies and programs

Terminology

This section defines terms used in this guide. For more details, see the PCI DSS glossary.

CHD

cardholder data. At a minimum, consists of the full primary account number (PAN). Cardholder data might also appear in the form of the full PAN plus any of the following:

  • Cardholder name
  • Expiration date and/or service code
  • Sensitive authentication data (SAD)
CDE

cardholder data environment. The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data.

PAN

primary account number. A key piece of cardholder data that you are obligated to protect under PCI DSS. The PAN is generally a 16-digit number that is unique to a payment card (credit and debit) and that identifies the issuer and the cardholder account.

PIN

personal identification number. A numeric password known only to the user and a system; used to authenticate the user to the system.

QSA

qualified security assessor. A person who is certified by the PCI Security Standards Council to perform audits and compliance analysis.

SAD

sensitive authentication data. In PCI compliance, data used by the issuers of cards to authorize transactions. Similar to cardholder data, PCI DSS requires protection of SAD. Additionally, SAD can't be retained by merchants and their payment processors. SAD includes the following:

  • "Track" data from magnetic stripes
  • "Track equivalent data" generated by chip and contactless cards
  • Security validation codes (for example, the 3-4 digit number printed on cards) used for online and card-not-present transactions.
  • PINs and PIN blocks
segmentation

In the context of PCI DSS, the practice of isolating the CDE from the remainder of the entity's network. Segmentation is not a PCI DSS requirement. However, it is strongly recommended as a method that can help to reduce the following:

  • The scope and cost of the PCI DSS assessment
  • The cost and difficulty of implementing and maintaining PCI DSS controls
  • The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)

Segment your cardholder data environment

The cardholder data environment (CDE) comprises people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. In the context of GKE, the CDE also comprises the following:

  • Systems that provide security services (for example, IAM).
  • Systems that facilitate segmentation (for example, projects, folders, firewalls, virtual private clouds (VPCs), and subnets).
  • Application pods and clusters that store, process, or transmit cardholder data. Without adequate segmentation, your entire cloud footprint can get in scope for PCI DSS.

To be considered out of scope for PCI DSS, a system component must be properly isolated from the CDE such that even if the out-of-scope system component were compromised, it could not impact the security of the CDE.

An important prerequisite to reduce the scope of the CDE is a clear understanding of business needs and processes related to the storage, processing, and transmission of cardholder data. Restricting cardholder data to as few locations as possible by eliminating unnecessary data and consolidating necessary data might require you to reengineer long-standing business practices.

You can properly segment your CDE through a number of means on Google Cloud. This section discusses the following means:

  • Logical segmentation by using the resource hierarchy
  • Network segmentation by using VPCs and subnets
  • Service level segmentation by using VPC
  • Other considerations for any in-scope cluster

Logical segmentation using the resource hierarchy

There are several ways to isolate your CDE within your organizational structure using Google Cloud's resource hierarchy. Google Cloud resources are organized hierarchically. The Organization resource is the root node in the Google Cloud resource hierarchy. Folders and projects fall under the Organization resource. Folders can contain projects and folders. Folders are used to control access to resources in the folder hierarchy through folder-level IAM permissions. They're also used to group similar projects. A project is a trust boundary for all your resources and an IAM enforcement point.

You might group all projects that are in PCI scope within a folder to isolate at the folder level. You might also use one project for all in-scope PCI clusters and applications, or you might create a project and cluster for each in-scope PCI application and use them to organize your Google Cloud resources. In any case, we recommend that you keep your in-scope and out-of-scope workloads in different projects.

Network segmentation using VPC networks and subnets

You can use Virtual Private Cloud (VPC) and subnets to provision your network and to group and isolate CDE-related resources. VPC is a logical isolation of a section of a public cloud. VPC networks provide scalable and flexible networking for your Compute Engine virtual machine (VM) instances and for the services that leverage VM instances, including GKE. For more details, see the VPC overview and refer to the best practice and reference architectures.

Service-level segmentation using VPC Service Controls and Google Cloud Armor

While VPC and subnets provide segmentation and create a perimeter to isolate your CDE, VPC Service Controls augments the security perimeter at layer 7. You can use VPC Service Controls to create a perimeter around your in-scope CDE projects. VPC Service Controls gives you the following controls:

  • Ingress control. Only authorized identities and clients are allowed into your security perimeter.
  • Egress control. Only authorized destinations are allowed for identities and clients within your security perimeter.

You can use Google Cloud Armor to create lists of IP addresses to allow or deny access to your HTTP(S) load balancer at the edge of the Google Cloud network. By examining IP addresses as close as possible to the user and to malicious traffic, you help prevent malicious traffic from consuming resources or entering your VPC networks.

Use VPC Service Controls to define a service perimeter around your in-scope projects. This perimeter governs VM-to-service and service-to-service paths, as well as VPC ingress and egress traffic.

Figure 1. Achieving segmentation using VPC Service Controls.
Figure 1. Achieving segmentation using VPC Service Controls

Build and maintain a secure network and systems

Building and maintaining a secure network encompasses requirements 1 and 2 of PCI DSS.

Requirement 1

Install and maintain a firewall configuration to protect cardholder data and traffic into and out of the CDE.

Networking concepts for containers and GKE differ from those for traditional VMs. Pods can reach each other directly, without NAT, even across nodes. This creates a simple network topology that might be surprising if you're used to managing more complex systems. The first step in network security for GKE is to educate yourself on these networking concepts.

Logical layout of a secure Kubernetes cluster.
Figure 2. Logical layout of a secure Kubernetes cluster

Before diving into individual requirements under Requirement 1, you might want to review the following networking concepts in relation to GKE:

  • Firewall rules. Firewall rules are used to restrict traffic to your nodes. GKE nodes are provisioned as Compute Engine instances and use the same firewall mechanisms as other instances. Within your network, you can use tags to apply these firewall rules to each instance. Each node pool receives its own set of tags that you can use in rules. By default, each instance belonging to a node pool receives a tag that identifies a specific GKE cluster that this node pool is a part of. This tag is used in firewall rules that GKE creates automatically for you. You can add custom tags at either cluster or node pool creation time by using the --tags flag in the Google Cloud CLI.

  • Network policies. Network policies let you limit network connections between pods, which can help restrict network pivoting and lateral movement inside the cluster in the event of a security issue with a pod. To use network policies, you must enable the feature explicitly when creating the GKE cluster. You can enable it on an existing cluster, but it will cause your cluster nodes to restart. The default behavior is that all pod-to-pod communication is always open. Therefore, if you want to segment your network, you need to enforce pod-level networking policies. In GKE, you can define a network policy by using the Kubernetes Network Policy API or by using the kubectl tool. These pod-level traffic policy rules determine which pods and services can access one another inside your cluster.

  • Namespaces. Namespaces allow for resource segmentation inside your Kubernetes cluster. Kubernetes comes with a default namespace out of the box, but you can create multiple namespaces within your cluster. Namespaces are logically isolated from each other. They provide scope for pods, services, and deployments in the cluster, so that users interacting with one namespace will not see content in another namespace. However, namespaces within the same cluster don't restrict communication between namespaces; this is where network policies come in. For more information on configuring namespaces, see the Namespaces Best Practices blog post.

The following diagram illustrates the preceding concepts in relation to each other and other GKE components such as cluster, node, and pod.

A Kubernetes network policy controlling traffic within a
cluster.
Figure 3. A Kubernetes network policy controlling traffic within a cluster

Requirement 1.1

Processes and mechanisms for installing and maintaining network security controls are defined and understood.

Requirement 1.1.2

Describe groups, roles, and responsibilities for managing network components.

First, as you would with most services on Google Cloud, you need to configure IAM roles in order to set up authorization on GKE. When you've set up your IAM roles, you need to add Kubernetes role-based access control (RBAC) configuration as part of a Kubernetes authorization strategy.

Essentially, all IAM configuration applies to any Google Cloud resources and all clusters within a project. Kubernetes RBAC configuration applies to the resources in each Kubernetes cluster, and enables fine-grained authorization at the namespace level. With GKE, these approaches to authorization work in parallel, with a user's capabilities effectively representing a union of IAM and RBAC roles assigned to them:

  • Use IAM to control groups, roles, and responsibilities for logical management of network components in GKE.
  • Use Kubernetes RBAC to grant granular permissions to network policies within Kubernetes clusters, to control pod-to-pod traffic, and to prevent unauthorized or accidental changes from non-CDE users.
  • Be able to justify for all IAM and RBAC users and permissions. Typically, when QSAs test for controls, they look for a business justification for a sample of IAM and RBAC.

Requirement 1.2

Network security controls (NSCs) are configured and maintained.

First, you configure firewall rules on Compute Engine instances that run your GKE nodes. Firewall rules protect these cluster nodes.

Next, you configure network policies to restrict flows and protect pods in a cluster. A network policy is a specification of how groups of pods are allowed to communicate with each other and with other network endpoints. You can use GKE's network policy enforcement to control the communication between your cluster's pods and services. To further segment your cluster, create multiple namespaces within it. Namespaces are logically isolated from each other. They provide scope for pods, services, and deployments in the cluster, so users interacting with one namespace will not see content in another namespace. However, namespaces within the same cluster don't restrict communication between namespaces; this is where network policies come in. Namespaces allow for resource segmentation inside your Kubernetes cluster. For more information on configuring namespaces, see the Namespaces Best Practices blog post.

By default, if no policies exist in a namespace, then all ingress and egress traffic is allowed to and from pods in that namespace. For example, you can create a default isolation policy for a namespace by creating a network policy that selects all pods but doesn't allow any ingress traffic to those pods.

Requirement 1.2.2

All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1.

To treat your networking configurations and infrastructure as code, you need to establish a continuous integration and continuous delivery (CI/CD) pipeline as part of your change-management and change-control processes.

You can use Cloud Deployment Manager or Terraform templates as part of the CI/CD pipeline to create network policies on your clusters. With Deployment Manager or Terraform, you can treat configuration and infrastructure as code that can reproduce consistent copies of the current production or other environments. Then you are able to write unit tests and other tests to ensure your network changes work as expected. A change control process that includes an approval can be managed through configuration files stored in a version repository.

With Terraform Config Validator, you can define constraints to enforce security and governance policies. By adding Config Validator to your CI/CD pipeline, you can add a step to any workflow. This step validates a Terraform plan and rejects it if violations are found.

Requirement 1.2.5

All services, protocols, and ports allowed are identified, approved, and have a defined business need.

For strong ingress controls for your GKE clusters, you can use authorized networks to restrict certain IP ranges that can reach your cluster's control plane. GKE uses both Transport Layer Security (TLS) and authentication to provide secure access to your cluster master endpoint from the public internet. This access gives you the flexibility to administer your cluster from anywhere. By using authorized networks, you can further restrict access to specified sets of IP addresses.

You can use Google Cloud Armor to create IP deny lists and allow lists and security policies for GKE hosted applications. In a GKE cluster, incoming traffic is handled by HTTP(S) Load Balancing, which is a component of Cloud Load Balancing. Typically, the HTTP(S) load balancer is configured by the GKE ingress controller, which gets configuration information from a Kubernetes Ingress object. For more information, see how to configure Google Cloud Armor policies with GKE.

Requirement 1.3

Network access to and from the cardholder data environment is restricted.

To keep sensitive data private, you can configure private communications between GKE clusters inside your VPC networks and on-premises hybrid deployments by using VPC Service Controls and Private Google Acc