About FIPS-validated encryption in GKE

This page describes how Google Cloud and Google Kubernetes Engine (GKE) maintain compliance with the Federal Information Processing Standards (FIPS) as you process and transmit data through your GKE clusters that run on Google Cloud.

This page is intended for Security managers, Security engineers, and Compliance officers who want to meet strict data security and privacy requirements related to FIPS. This page is also useful if you need to show an auditor that GKE on Google Cloud implements FIPS-validated protections for data security by default.

Key takeaways about FIPS-validated encryption in GKE

  • The FedRAMP® security controls for data encryption in transit (SC-28) and at rest (SC-8(1)) require that your data is encrypted using FIPS 140-2 validated cryptographic modules or newer. These security controls don't explicitly mandate enabling "FIPS mode" at the operating system (OS) level. Additionally, OS-level FIPS mode isn't a guarantee of compliance.
  • Data that's stored in FedRAMP authorized Google Cloud systems is encrypted at rest by default using FIPS 140-2 validated cryptographic modules or newer. As long as your data is stored in these authorized systems, the data meets the FedRAMP requirements for protecting data at rest (security control SC-28). For a list of authorized systems, see the FedRAMP High services in scope.
  • Data that you transmit inside the Google Cloud Virtual Private Cloud (VPC) network is automatically encrypted and is protected by authentication and authorization mechanisms. VPC is authorized at FedRAMP High. As long as your data is being transmitted within the Google Cloud VPC network, the data meets the FedRAMP requirements for protecting data in transit (security control SC-8(1)).
  • You don't need to build your applications using FIPS-compliant build processes to meet the FedRAMP requirements for data protection at rest and in transit. This is because data that's transmitted within the Google Cloud VPC network and is stored in FedRAMP authorized Google Cloud storage systems is protected in compliance with these FedRAMP requirements for data protection by default.

About FIPS and FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) is a US government program that defines a standardized approach to security and risk assessment for cloud technologies. GKE is included in the list of Google Cloud services that have FedRAMP High provisional authority to operate (P-ATO). To learn more about the Google Cloud FedRAMP P-ATO, see the Google Cloud FedRAMP overview.

FIPS is a publicly announced set of standards issued by the National Institute of Standards and Technology (NIST). FIPS publication 140-2 defines the requirements for approving cryptographic modules. For details, see FIPS 140-2 on NIST.

The FedRAMP High P-ATO includes controls for protecting data in transit (SC-8(1)) and protecting data at rest (SC-28(1)) using FIPS-validated cryptographic modules.

Default FIPS-validated data protection in GKE

The following sections explain how Google Cloud and GKE implement FIPS-validated encryption to protect data at rest and in transit. This information is covered in more detail in the Google Cloud system security plan (SSP), which you can request from your Google Cloud sales team, Google Cloud representative, or from the Google Cloud FedRAMP Program Management Office if you're a government customer. For details, see Google Cloud FedRAMP Compliance.

FIPS-validated data protection at rest

GKE data is encrypted at rest using a FIPS 140-2 validated Google Cloud encryption module named BoringCrypto. For details, see FIPS 140-2 validation in Google Cloud.

For more information about encryption at rest, see the following resources:

FIPS-validated data protection in transit

The Google Cloud VPC has a FedRAMP High P-ATO. Any data that you transmit within your VPC network is automatically encrypted. In GKE, this means that all traffic to and from containers, Pods, the kubelet process on each node, all nodes, control plane instances, and other Google Cloud services within the VPC is protected in transit. All connections to Google APIs use transport layer security (TLS) 1.2 or higher to encrypt network traffic. No additional action is needed to be FIPS-compliant for data protection in transit within the Google Cloud VPC network.

For more information about how your data is encrypted in transit, see the Encryption in transit whitepaper.

Recommendations for protecting data outside of Google Cloud

The default encryption of data in transit for GKE and Google Cloud apply only within the Google Cloud VPC network. You must use FIPS-compliant cryptography to protect data that's outside of the VPC network boundary. The following recommendations help you to ensure that all incoming and outgoing data outside of your Google Cloud FIPS environment in transit is encrypted with FIPS-compliant cryptography.

Intercept and encrypt incoming traffic from the internet

For incoming traffic to your Google Cloud environment from the internet, use SSL policies in Google Cloud load balancers to define an allowed set of FIPS-validated cryptographic ciphers or mechanisms with which the data must be protected when it enters the Google Cloud environment. For details, see the following resources:

Intercept and encrypt outbound traffic to the internet

Define a perimeter that limits outbound data connections to a set of known third parties that you trust by configuring firewalls. Diagram and document any external network requirements, such as pulling data from sources like GitHub, and where those external connections will occur within your environment. Consider using a reverse proxy to intercept outbound traffic from your VPC.

If you have HTTP traffic that's leaving the perimeter of your FedRAMP-compliant Google Cloud environment, consider setting up an HTTP forward proxy to intercept the data before it leaves the environment. Re-encrypt the data using a FIPS 140-2 validated cryptographic module before you allow it to leave your perimeter. This approach is more manageable at scale than trying to ensure that every internal client uses compliant encryption libraries for external communication.

Enable private nodes

GKE lets you disable the external IP address for new nodes in your clusters, so that workloads that run on the nodes can't communicate with the internet by default. Use the http_proxy or https_proxy environment variables to send all traffic to your configured HTTP proxy.

You can configure more transparent interception of this traffic with routing rules. However, because you're proxying TLS traffic, the proxy can't be completely transparent to the applications you run on GKE.

For details, see the following resources:

Use Cloud VPN for network layer connections to GKE

You might sometimes need an encrypted network layer connection to your GKE clusters. For example, you might need to set up FIPS-compliant networking between GKE nodes and on-premises nodes. Cloud VPN is a FedRAMP High authorized service that encrypts your data in transit between your VPC network and your on-premises network. For details, see Cloud VPN overview.

Use Cloud KMS for cryptographic operations

If you need to perform cryptographic operations in your Google Cloud environment, use Cloud Key Management Service. Cloud KMS is a FedRAMP High authorized service. Cloud KMS lets you perform cryptographic operations that comply with either FIPS 140-2 Level 1 or Level 3. For details, see the following resources:

Build FIPS-validated libraries in GKE workloads

To use the BoringCrypto encryption module in your GKE applications, install BoringSSL. BoringSSL is an open source fork of OpenSSL that includes the BoringCrypto library. To build, compile, and statically link the BoringCrypto module to BoringSSL, see section 12.1, "Installation Instructions", in the BoringCrypto FIPS 140-2 Security Policy PDF

Consider third-party FIPS-compliant container images

We recommend that you use proxies at the boundary of your FIPS-compliant Google Cloud environment to comprehensively enforce FIPS compliance. You can also run FIPS-compliant workloads without being limited to node host machines that have FIPS-compliant kernels. Some third-party vendors provide container images that use a separate, FIPS-compliant source of entropy.

Ensure that you properly evaluate the third-party vendor's implementation to ensure that it's actually FIPS-compliant.

What's next