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 (GKE) 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, adheres to PCI DSS requirements. We outline our responsibilities in our customer responsibility matrix.
- Customers who want to bring PCI-compliant workloads to Google Cloud that involve GKE (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 (DLP) API
- Identity-Aware Proxy (IAP)
- Security Command Center
This guide is intended for those who are familiar with containers and GKE.
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 3.2.1 of the standard. This guide doesn't cover all the requirements in PCI DSS.
This section defines terms used in this guide. For more details, see the PCI DSS glossary.
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)
cardholder data environment. The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data.
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.
personal identification number. A numeric password known only to the user and a system; used to authenticate the user to the system.
qualified security assessor. A person who is certified by the PCI Security Standards Council to perform audits and compliance analysis.
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
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. One way of accomplishing PCI segmentation is with the GKE PCI Terraform starter kit.
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.
Build and maintain a secure network
Building and maintaining a secure network encompasses requirements 1 and 2 of PCI DSS.
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.
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
--tagsflag in the
gcloudcommand-line tool. See this article on configuring firewall rules for GKE nodes.
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
kubectltool. 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.
Create a formal process for approving and testing all network connections and changes to the firewall and router configurations.
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.
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.
Build firewall and router configurations that restrict connections between untrusted networks and any system components in the CDE.
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.
Restrict inbound and outbound traffic to that which is necessary for the CDE, and explicitly deny all other traffic.
For strong ingress controls for your GKE clusters, you can use authorized networks to restrict (or whitelist) 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.
Prohibit direct public access between the internet and any system component in the CDE.
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 Access.
Limit inbound internet traffic to IP addresses within the DMZ.
Consider implementing Cloud NAT setup with GKE to limit inbound internet traffic to only that cluster. You can set up a private cluster for the non-public facing clusters in your CDE. In a private cluster, the nodes have internal RFC 1918 IP addresses only, which ensures that their workloads are isolated from the public internet.
Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.
You implement anti-spoofing measures by using alias IP addresses on GKE pods and clusters to detect and block forged source IP addresses from entering the network. A cluster that uses alias IP ranges is called a VPC-native cluster.
Do not disclose private IP addresses and routing information to unauthorized parties.
You can use a GKE IP masquerade agent to do network address translation (NAT) for many-to-one IP address translations on a cluster. Masquerading masks multiple source IP addresses behind a single address.
Do not use vendor-supplied defaults for system passwords and other security parameters. Requirement 2 specifies how to harden security parameters by removing defaults and vendor supplied credentials. Hardening your cluster is a customer responsibility.
Develop configuration standards for all system components. Ensure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to:
Enable only necessary services, protocols, daemons, etc. as required for the function of the system.
Configure system security parameters to prevent misuse.
Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
Before you move containers onto GKE, we recommend the following:
- Start with a container managed base image that is built, maintained, and vulnerability-checked by a trusted source. Consider creating a set of "known good" or "golden" base images that your developers can use. A more restrictive option is to use a distroless image or a scratch base image.
- Use Container Analysis to scan your container images for vulnerabilities.
- Establish an internal DevOps/SecOps policy to include only approved, trusted libraries and binaries into the containers.
During set up, we recommend the following:
- Use the default Container-Optimized OS as the node image for GKE. Container-Optimized OS is based on Chromium OS and is optimized for node security.
- Enable auto-upgrading nodes for the clusters that run your applications. This feature automatically upgrades the node to the Kubernetes version that's running in the managed control plane, providing better stability and security.
- Enable auto-repairing nodes. When this feature is enabled, GKE periodically checks and uses the node's health status to determine if a node needs to be repaired. If a node requires repair, that node is drained and a new node is created and added to the cluster.
- Turn on Cloud Monitoring and Cloud Logging for visibility of all events, including security events and node health status. Create Cloud Monitoring alert policies to get notified if a security incident occurs.
- Apply least privilege service accounts for GKE nodes
- Review and apply (where applicable) the GKE section in the
Google Cloud CIS Benchmark
guide. Kubernetes audit logging is already enabled by default, and logs for
both requests to
kubectland the GKE API are written to Cloud Audit Logs.
- Configure audit logging.
Protect cardholder data
Protecting cardholder data encompasses requirements 3 and 4 of PCI DSS.
Protect stored cardholder data.
Requirement 3 of PCI DSS stipulates that protection techniques such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person.
You might also consider other methods of protecting stored data as potential risk-mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if the full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as email and instant messaging.
Examples of systems where CHD might persist as part of your payment processing flows when running on Google Cloud are:
- Cloud Storage buckets
- BigQuery instances
- Cloud SQL
Be aware that CHD might be inadvertently stored in email or customer service communication logs. It's prudent to use Cloud DLP (DLP) to filter these data streams so that you limit your in-scope environment to the payment processing systems.
Note that on Google Cloud, data is encrypted at rest by default, and encrypted in transit by default when it traverses physical boundaries. No additional configuration is necessary to enable these protections.
- One-way hashes based on strong cryptography (hash must be of the entire PAN).
- Truncation (hashing cannot be used to replace the truncated segment of PAN).
- Index tokens and pads (pads must be securely stored).
- Strong cryptography with associated key-management processes and procedures.
One mechanism to render PAN data unreadable is tokenization. For more information, see the solution guide on tokenizing sensitive cardholder data for PCI DSS.
You can use the DLP API to scan, discover, and report the cardholder data. Cloud DLP has native support for scanning and classifying 12–19-digit PAN data in Cloud Storage, BigQuery, and Datastore. It also has a streaming content API to enable support for additional data sources, custom workloads, and applications. You can also use the DLP API to truncate (redact) or hash the data.
Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.
Cloud Key Management Service (KMS) is a managed storage system for cryptographic keys. It can generate, use, rotate, and destroy cryptographic keys. Although Cloud KMS does not directly store secrets like cardholder data, it can be used to encrypt such data.
Secrets in the context of Kubernetes are Kubernetes secret objects that let you store and manage sensitive information, such as passwords, tokens, and keys.
By default, Google Cloud encrypts customer content stored at rest. GKE handles and manages this default encryption for you without any additional action on your part. Application-layer secrets encryption provides an additional layer of security for sensitive data such as secrets. Using this functionality, you can provide a key that you manage in Cloud KMS, to encrypt data at the application layer. This protects against attackers who gain access to a copy of the Kubernetes configuration storage instance of your cluster.
Encrypt transmission of cardholder data across open, public networks.
The in-scope data must be encrypted during transmission over networks that are easily accessed by malicious individuals, for example, public networks.
Istio is an open source service mesh that layers transparently onto existing distributed applications. Istio scalably manages authentication, authorization, and encryption of traffic between microservices. It's a platform that includes APIs that let you integrate into any logging platform, telemetry, or policy system. Istio's feature set lets you efficiently run a distributed microservice architecture and provides a uniform way to secure, connect, and monitor microservices.
- Only trusted keys and certificates are accepted.
- The protocol in use only supports secure versions or configurations.
- The encryption strength is appropriate for the encryption methodology in use.
You can use Istio to create a network of deployed services—with load balancing, service-to-service authentication, and monitoring. You can also use it to deliver secure service-to-service communication in a cluster—with strong identity-based authentication and authorization based on mutual TLS. Mutual TLS (mTLS) is a TLS handshake performed twice, establishing the same level of trust in both directions (as opposed to one-directional client-server trust).
Istio lets you deploy TLS certificates to each of the GKE pods within an application. Services running on the pod can use mTLS to strongly identify their peer identities. Service-to-service communication is tunneled through client-side and server-side Envoy proxies. Envoy uses SPIFFE IDs to establish mTLS connections between services. For information on how to deploy Istio on GKE, see the GKE documentation. And for information on supported TLS versions, see the Istio Traffic Management reference. Use TLS version 1.1 at minimum, preferably TLS 1.2 and later.
If your application is exposed to the internet, use GKE HTTP(S) Load Balancing with ingress routing that is set to use HTTP(S). HTTP(S) Load Balancing, configured by an Ingress object, includes the following features:
- Flexible configuration for services. An Ingress object defines how traffic reaches your services and how the traffic is routed to your application. In addition, an Ingress can provide a single IP address for multiple services in your cluster.
- Integration with Google Cloud network services. An Ingress object can configure Google Cloud features such as Google-managed SSL certificates (beta), Google Cloud Armor, Cloud CDN, and Identity-Aware Proxy.
- Support for multiple TLS certificates. An Ingress object can specify the use of multiple TLS certificates for request termination.
Maintain a vulnerability management program
Maintaining a vulnerability management program encompasses requirements 5 and 6 of PCI DSS.
Use and regularly update antivirus software or programs.
Requirement 5 of PCI DSS stipulates that antivirus software must be used on all systems commonly affected by malware to protect systems from current and evolving malicious software threats—and containers are no exception.
Deploy antivirus software on all systems commonly affected by malicious software (particularly personal computers and servers).
You must implement vulnerability management programs for your container images.
We recommend the following actions:
- Regularly check and apply up-to-date security patches on the containers.
- Perform regular vulnerability scanning against containerized applications and binaries/libraries.
- Scan images as part of the build pipeline.
- Subscribe to a vulnerability intelligence service to receive up-to-date vulnerability information relevant to the environment and libraries used in the containers
Google Cloud works with various container security solutions providers to improve security posture within customers' Google Cloud deployments. We recommend leveraging validated security solutions and technologies to increase depth of defense in your GKE environment. For the latest Google Cloud-validated security partners list, see the "Container Security" section in Google Cloud: Security Partner Ecosystem.
Ensure that antivirus programs are capable of detecting, removing, and protecting against all known types of malicious software.
For systems exempted from 5.1.1, perform periodic evaluations to identify and evaluate evolving malware threats.
There are many solutions available to perform antivirus scans, but PCI DSS recognizes that not all systems are equally likely to be vulnerable. It's common for merchants to declare their Linux servers, mainframes, and similar machines as not "commonly affected by malicious software" and therefore exempt from 5.1.1. In that case, 5.1.2 applies, and you must implement a system for periodic threat evaluations.
Keep in mind that these rules apply to both nodes and pods within a GKE cluster.
- Are kept current.
- Perform periodic scans.
- Generate audit logs that are retained per PCI DSS requirement 10.7.
Ensure that antivirus mechanisms are actively running and cannot be disabled or altered by users, unless explicitly authorized by management on a case-by-case basis for a limited time period.
Requirements 5.1, 5.2, and 11.5 call for antivirus scans and file integrity monitoring (FIM) on any in-scope host. We recommend implementing a solution where all nodes can be scanned by a trusted agent within the cluster or where each node has a scanner that reports up to a single management endpoint.
A common solution to both the antivirus and FIM requirements is to lock down your container so only specific allowed folders have write access. To do this, you run your containers as a non-root user and use file system permissions to prevent write access to all but the working directories within the container file system. Disallow privilege escalation to avoid circumvention of the file system rules.
Develop and maintain secure systems and applications.
Requirement 6 of PCI DSS stipulates that you establish a strong software development lifecycle where security is built in at every step of software development.
Establish a process to identify security vulnerabilities, using reputable outside sources, and assign a risk ranking (for example, high, medium, or low) to newly discovered security vulnerabilities.
Security in the cloud is a shared responsibility between the cloud provider and the customer.
In GKE, Google manages the control plane, which includes the
master VMs, the API server, and other components running on those VMs, as well
etcd database. This includes upgrades and patching, scaling, and
repairs, all backed by a service-level objective (SLO). For the nodes' operating
system, such as Container-Optimized OS or Ubuntu, GKE
promptly makes any patches to these images available. If you have auto-upgrade
enabled, these patches are automatically deployed. (This is the base layer of
your container—it's not the same as the operating system running in your
For more information on the GKE shared responsibility model, see Exploring container security: the shared responsibility model in GKE.
Google provides several security services to help build security into your CI/CD pipeline. To identify vulnerabilities in your container images, you can use Google Container Analysis Vulnerability Scanning. When a container image is pushed to Google Container Registry (GCR), vulnerability scanning automatically scans images for known vulnerabilities and exposures from known CVE sources. Vulnerabilities are assigned severity levels (critical, high, medium, low, and minimal) based on CVSS scores.
Develop internal and external software applications including web-based administrative access to applications in accordance with PCI DSS and based on industry best practices. Incorporate information security throughout the software development lifecycle. This applies to all software developed internally as well as bespoke or custom software developed by a third party.
You can use Binary Authorization to help ensure that only trusted containers are deployed to GKE. If you want to enable only images authorized by one or more specific attestors, you can configure Binary Authorization to enforce a policy with rules that require attestations based on vulnerability scan results. You can also write policies that require one or more trusted parties (called "attestors") to approve of an image before it can be deployed. For a multi-stage deployment pipeline where images progress from development to testing to production clusters, you can use attestors to ensure that all required processes have completed before software moves to the next stage.
At deployment time, Binary Authorization enforces your policy by checking that the container image has passed all required constraints—including that all required attestors have verified that the image is ready for deployment. If the image passes, the service allows it to be deployed. Otherwise, deployment is blocked and the image can't be deployed until it's compliant.
For more information on setting up Binary Authorization, see the solution guide on securing software supply chains on GKE.
GKE Sandbox reduces the need for the container to interact directly with the host, shrinking the attack surface for host compromise, and restricting the movement of malicious actors.
Ensure all public-facing web applications are protected against known attacks, either by performing application vulnerability assessment at least annually and after any changes.
Web Security Scanner allows you to scan publicly facing App Engine, Compute Engine, and GKE web applications for common vulnerabilities ranging from cross-site scripting and misconfigurations to vulnerable resources. Scans can be performed on demand and scheduled from the Cloud Console. Using the Security Scanner APIs, you can automate the scan as part of your security test suite in your application build pipeline.
Implement strong access control measures
Implementing strong access control measures encompasses requirements 7, 8, and 9 of PCI DSS.
Restrict access to cardholder data by business need to know.
Requirement 7 focuses on least privilege or need to know. PCI DSS defines these as granting access to the least amount of data and providing the fewest priveleges that are required in order to perform a job.
Limit access to system components and cardholder data to only those individuals whose job requires such access.
IAM and Kubernetes role-based access control (RBAC) work together to provide fine-grained access control to your GKE environment. IAM is used to manage user access and permissions of Google Cloud resources in your CDE project. In GKE, you can also use IAM to manage the access and actions that users and service accounts can perform in your clusters, such as creating and deleting clusters.
Kubernetes RBAC allows you to configure fine-grained sets of permissions that define how a given Google Cloud user, Google Cloud service accounts, or group of users (Google Groups) can interact with any Kubernetes object in your cluster, or in a specific namespace of your cluster. Examples of RBAC permissions include editing deployments or configmaps, deleting pods, or viewing logs from a pod. You grant users or services limited IAM permissions, such as Google Kubernetes Engine Cluster Viewer or custom roles, then apply Kubernetes RBAC RoleBindings as appropriate.
Cloud Identity Aware Proxy (IAP) can be integrated through ingress for GKE to control application-level access for employees or people who require access to your PCI applications.
Additionally, you can use Organization policies to restrict the APIs and services that are available within a project.
Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities.
Along with making sure users and service accounts adhere to the principle of least privilege, containers should too. A best practice when running a container is to run the process with a non-root user. You can accomplish and enforce this practice by using pod security policies.
PodSecurityPolicy is an admission controller resource you create that
validates requests to create and update pods on your cluster. The
PodSecurityPolicy defines a set of conditions that pods must meet to be
accepted by the cluster; when a request to create or update a pod does not meet
the conditions in the
PodSecurityPolicy, that request is rejected and an error
example YAML file,
PodSecurityPolicy disallows containers that require root privileges and
limits the volume types to a restricted list.
Assign a unique ID to each person with computer access.
Requirement 8 specifies that a unique ID must be assigned to each person who has access to in-scope PCI systems to ensure that each individual is uniquely accountable for their actions.
Assign all users a unique ID before allowing them to access system components or cardholder data.
Immediately revoke access for any terminated users.
Both IAM and Kubernetes RBAC can be used to control access to your GKE cluster, and in both cases you can grant permissions to a user. We recommend that the users tie back to your existing identity system, so that you can manage user accounts and policies in one location.
- Something you know, such as a password or passphrase.
- Something you have, such as a token device or smart card.
- Something you are, such as a biometric.
Certificates are bound to a user's identity when
they authenticate to
All GKE clusters are configured to accept Google Cloud user
and service account identities, by validating the credentials and retrieving the
email address associated with the user or service account identity. As a result,
the credentials for those accounts must include the
userinfo.email OAuth scope
in order to successfully authenticate.
Restrict physical access to cardholder data.
Google is responsible for physical security controls on all Google Data Centers underlying Google Cloud.
Regularly monitor and test networks
Regularly monitoring and testing networks encompasses requirements 10 and 11 of PCI DSS.
Track and monitor all access to network resources and cardholder data.
Implement audit trails to link all access to system components to each individual user.
Kubernetes clusters have Kubernetes audit logging enabled by default, which keeps a chronological record of calls that have been made to the Kubernetes API server. Kubernetes audit log entries are useful for investigating suspicious API requests, for collecting statistics, or for creating monitoring alerts for unwanted API calls.
In addition to entries written by Kubernetes, your project's audit logs have entries written by GKE.
To differentiate your CDE and non-CDE workloads, we recommend that you add labels to your GKE pods that will percolate into metrics and logs emitted from those workloads.
- 10.3.1: User identification
- 10.3.2: Type of event
- 10.3.3: Date and time
- 10.3.4: Success or failure indication
- 10.3.5: Origination of event
- 10.3.6: Identity or name of affected data, system component, or resource
Every audit log entry in Logging is an object of type
that contains the following fields:
- A payload, which is of the
protoPayloadtype. The payload of each audit log entry is an object of type
AuditLog. You can find the user identity in the
- The specific event, which you can find in the
- A timestamp. (10.3.3)
- The event status, which you can find in the
responseobjects in the
- The operation request, which you can find in the
requestMetadataobjects in the
- The service that is going to be performed, which you can find in the
Regularly test security systems and processes.
Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify 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.
Container Analysis vulnerability scanning performs the following types of vulnerability scanning for the images in Container Registry:
Initial scanning. When you first activate the Container Analysis API, it scans your images in Container Registry and extracts package manager, image basis, and vulnerability occurrences for the images.
Incremental scanning. Container Analysis scans new images when they're uploaded to Container Registry.
Continuous analysis: As Container Analysis receives new and updated vulnerability information from vulnerability sources, it reruns analysis of containers to keep the list of vulnerability occurrences for already scanned images up to date.
Use intrusion detection (IDS) and/or intrusion-prevention (IPS) techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the CDE as well as at critical points in the CDE and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines and signatures up to date.
Google Cloud Packet Mirroring can be used with a 3rd party IDS such as Palo Alto Networks to detect network intrusions. Google Cloud packet mirroring forwards all network traffic from your Compute Engine VMs or Google Cloud clusters to a designated address. An IDS such as Palo Alto Networks can consume this mirrored traffic to detect a wide range of threats including exploit attempts, port scans, buffer overflows, protocol fragmentation, command and control (C2) traffic, and malware.
Security Command Center gives you centralized visibility into the security state of Google Cloud services (including GKE) and assets across your whole organization, which makes it easier to prevent, detect, and respond to threats. By using Security Command Center, you can see when high-risk threats such as malware, cryptomining, unauthorized access to Google Cloud resources, outgoing DDoS attacks, port scanning, and brute-force SSH have been detected based on your Cloud Logging logs.
Maintain an information security policy
A strong security policy sets the security tone and informs people what is expected of them. In this case, "people" refers to full-time and part-time employees, temporary employees, contractors, and consultants who have access to your CDE.
Maintain a policy that addresses information security for employees and contractors.
For information about requirement 12, see the Google Cloud PCI Shared Responsibility Matrix.
If you used any resources while following this article—for example, if you started new VMs or used the Terraform scripts—you can avoid incurring charges to your Google Cloud account by deleting the project where you used those resources.
- In the Cloud Console, go to the Manage resources page.
- In the project list, select the project that you want to delete and then click Delete delete.
- In the dialog, type the project ID and then click Shut down to delete the project.