Encryption in transit

This document provides details on GDCH encryption transit.

CIO-level summary

  • GDCH employs several security measures to help ensure the authenticity, integrity, and confidentiality of data in transit.
  • Depending on the connection that is being made, GDCH applies default protections to data in transit for GDCH components. For example, we secure communications between the user and the GDCH Anthos Service Mesh Ingress Gateway using TLS.


Security is often a deciding factor when choosing a cloud provider. At Google, security is of the utmost importance. We work tirelessly to protect your data — whether it is traveling over your network, moving within Google's infrastructure, or storing on our servers.

Central to Google's security strategy are authentication, integrity, and encryption, for both data at rest and in transit. This paper describes our approach to encryption in transit for Google Distributed Cloud Hosted (GDCH).

For data at rest, see Encryption at Rest. For an overview across all of Google Security, see Google Infrastructure Security Design Overview.

Audience: this document is aimed at CISOs and security operations teams using or considering GDCH.

Prerequisites: in addition to this introduction, we assume a basic understanding of encryption and cryptographic primitives.

Authentication, integrity, and encryption

GDCH employs several security measures to help ensure the authenticity, integrity, and confidentiality of data in transit.

  • Authentication: we authenticate the destination of the data on the network layer. The source is authenticated by GDCH-managed AIS.
  • Integrity: we make sure data you send arrives at its destination unaltered, that is protected from unauthorized changes.
  • Encryption: we make your data unreadable while in transit to keep it confidential. Encryption is the process through which legible data (plaintext) is made illegible (ciphertext) with the goal of ensuring the plaintext is only accessible by parties authorized by the owner of the data. The algorithms used in the encryption process are public, but the key required for decrypting the ciphertext is private. Encryption in transit often uses asymmetric key exchange, such as elliptic-curve-based Diffie-Hellman, to establish a shared symmetric key that is used for data encryption. For more information on encryption, see Introduction to Modern Cryptography.

Encryption can be used to protect data in multiple states:

  • Encryption at rest protects your data from a system compromise or data exfiltration by encrypting data while stored. The Advanced Encryption Standard (AES) is often used to encrypt data at rest.
  • Encryption in transit: protects your data if communications are intercepted while data moves between your site and the cloud provider or between two services. This protection is achieved by encrypting the data before transmission; authenticating the endpoints; and, on arrival, decrypting and verifying that the data was not modified. For example, transport layer security (TLS) is often used to encrypt data in transit for transport security, and Secure/Multipurpose Internet Mail Extensions (S/MIME) is used often for email message encryption.

Encryption is one component of a broader security strategy. Encryption in transit defends your data, after a connection is established and authenticated, against potential attackers by:

  • Removing the need to trust the lower layers of the network which are commonly provided by third parties
  • Reducing the potential attack surface
  • Preventing attackers from accessing data if communications are intercepted

With adequate authentication, integrity, and encryption, data that travels between users, devices, or processes can be protected in a hostile environment. The remainder of this paper explains GDCH approach to the encryption of data in transit and where it is applied.

GDCH network infrastructure

Physical boundaries

A physical boundary is the barrier to a physical space that is controlled by or in coordination with Google, where we can ensure that rigorous security measures are in place. Physical access to these locations is restricted, heavily monitored and audited. Only a small set of approved personnel have access to hardware. Data in transit within these physical boundaries is generally authenticated and encrypted.

For communication that crosses in or out of the physical boundary of GDCH, we employ strong authentication and encryption to protect data in transit.

How traffic gets routed

To understand how encryption in transit works in GDCH, it is necessary to explain how traffic gets routed to and through GDCH. This section describes how requests get from an end user to the appropriate GDCH service or customer application, and how traffic is routed between cross-site services.

A GDCH-managed service is a modular private cloud service. These services include compute, storage, and machine learning. For example, GDCH object storage is a GDCH-managed service. A customer application is an application hosted on GDCH that you, as a GDCH customer, can build and deploy using GDCH services. Customer applications or partner solutions that are hosted on GDCH are not considered GDCH-managed services. For example, an application you build using GDCH VMs, Database Service, and Vertex AI is a customer application.

Figure 1 shows different kinds of routing requests. Figure 1 shows interactions between the various network components, and the security in place for each connection.

Inter-site connectivity backbone infrastructure Figure 1: Inter-site connectivity infrastructure

End user (customer network) to GDCH API and managed service

For managed services hosted on Anthos Service Mesh Ingress Gateways, they accept requests from the customer network using Anthos Service Mesh Ingress Gateway. Anthos Service Mesh Ingress Gateway proxies traffic for incoming HTTP(S), and routes and load balances traffic to the GDCH-managed services themselves. Another firewall layer provides DDoS attack countermeasures with intrusion detection and prevention. This connection is authenticated and encrypted from Anthos Service Mesh Ingress Gateway to the frontend of the GDCH-managed service. Figure 1 shows this interaction as connection A.

Most GDCH APIs and managed services are hosted on Anthos Service Mesh Ingress Gateways. However, some services are hosted directly on GDCH-managed Layer 4 load balancer. For example, DBS databases are hosted on a GDCH external load balancer. These services are configured to authenticate and encrypt connections at the application layer using TLS. Figure 1 shows this interaction as connection B.

End user (customer network) to a customer application hosted on GDCH

There are several ways to route traffic from the customer network to a customer application hosted on GDCH. The way that your traffic is routed depends on your configuration.

Expose customer applications through customer API Gateway

GDCH supports exposing customer applications through the customer API Gateway. The customer API Gateway service empowers users to develop, deploy, secure, manage, and scale the API as needed. Figure 1 shows this interaction as connection C.

Expose containerized customer workloads through customer external load balancer

GDCH supports exposing containerized workloads that are managed by the customer through an external load balancer. GDCH provides the ability to configure ingress and egress policies to the corresponding personnel. Figure 1 shows this interaction as connection E.

Expose virtual machine workloads

GDCH supports exposing customer created Virtual Machines to end users. GDCH provides an ability to configure ingress and egress policies to the corresponding personnel. Figure 1 shows this interaction as connection F.

GDCH cross-site interconnect service

Routing from one managed service to another usually occurs entirely within the physical boundary of GDCH. In some cases, like cross-site backup, data is routed outside of the physical boundary of GDCH. In that case, data is encrypted both at the application layer, for example, TLS, and can also be encrypted at the network layer. Figure 1 shows this interaction as connection G.

Virtual machine to virtual machine

VM-to-VM connections within GDCH are not encrypted at the network level. Customers are responsible for encrypting data by using appropriate encrypted protocols or specific technologies like IPSecs tunnels.

Encryption in transit by default

GDCH uses various methods of encryption, both default and user configurable, for data in transit. The type of encryption used depends on the OSI layer, the type of service, and the physical component of the infrastructure. This section describes the default protections that Google uses to protect data in transit.

The remainder of this section describes the default protections that Google uses to protect data in transit.

User to Anthos Service Mesh Ingress Gateway encryption

Today, many systems use HTTPS to communicate over the Internet. HTTPS provides security by using a TLS connection, which ensures the authenticity, integrity, and confidentiality of requests and responses. To accept HTTPS requests, the receiver requires a public–private key pair and an X.509 certificate for server authentication from a Certificate Authority (CA). The key pair and certificate help authenticate a user's requests at the application layer (layer 7) by proving that the receiver owns the domain name for which requests are intended. The following subsections discuss the components of user to Anthos Service Mesh Ingress Gateway encryption, namely: TLS, BoringSSL, and GDCH Configurable Certificate Authority.

Transport layer security (TLS)

When you send a request to a GDCH service, we secure the data in transit; providing authentication, integrity, and encryption, using HTTPS with a certificate from a trusted certificate authority. Any data the user sends to the Anthos Service Mesh Ingress Gateway for the GDCH-managed service is encrypted in transit with transport layer security (TLS). Anthos Service Mesh Ingress Gateway negotiates a particular encryption protocol with the client depending on what the client can support. GDCH Anthos Service Mesh Ingress Gateway enforces only FIPS approved algorithms to provide stronger security.


BoringSSL is a Google-maintained, open source implementation of the TLS protocol, forked from OpenSSL, that is mostly interface-compatible with OpenSSL. Google forked BoringSSL from OpenSSL to simplify OpenSSL, both for internal use and to better support the Chromium and Android Open Source Projects. BoringCrypto, the core of BoringSSL, has been validated to FIPS 140-2 level 1.

TLS in the Anthos Service Mesh Ingress Gateway is implemented with BoringSSL. Table 1 shows the encryption protocols that GDCH supports when communicating with clients.

Protocols Authentication Key exchange Encryption Hash Functions
TLS 1.3 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256

Table 1: Encryption Implemented in the Anthos Service Mesh Ingress Gateway for GDCH Services and Implemented in the BoringSSL Cryptographic Library

GDCH configurable Certificate Authority

As part of TLS, a server must prove its identity to the user when it receives a connection request. This identity verification is achieved in the TLS protocol by having the server present a certificate containing its claimed identity. The certificate contains both the server's DNS hostname and its public key. Once presented, the certificate is signed by an issuing Certificate Authority (CA) that is trusted by the user requesting the connection. As a result, users who request connections to the server only need to trust the root CA. If the server wants to be accessed ubiquitously, the root CA needs to be known to any prospective client device. Client browsers and devices are configured with a set of root CAs that they trust, based on the environment that client is operating in.

The root CA for GDCH is dependent on the environment in which it is deployed, and the requirements of customers in that environment.

Anthos Service Mesh Ingress Gateway to application front ends

Two cases:

  • Anthos Service Mesh Ingress Gateway terminates TLS, re-encrypts mTLS using Anthos Service Mesh Istio certs
    • mTLS from Ingress Gateway to Istio Sidecar Application Frontend
  • Anthos Service Mesh Ingress Gateway terminates TLS, re-encrypts TLS to some other server, with configured CA.

Network encryption of storage traffic

In GDCH file and block storage system, traffic is routed between the application using the storage and the storage service. That data is authenticated and encrypted in transit using IPSec. Client-side encryption for the storage traffic is available soon. IPSec transport mode is used between file and block traffic to the host that needs to access storage. Authentication is done by a pre-shared key which is generated on the flight and securely stored in GDCH. Once IPSec SAs is established, information is exchanged using the IPSec tunnel. Packets are encrypted and decrypted using the FIPS compliant encryption crypto specified in the IPSec SA.

Service-to-service authentication, integrity, and encryption

Within GDCH infrastructure, at the application layer (layer 7), we use mTLS or TLS for the authentication, integrity, and encryption of RPC calls from the Anthos Service Mesh Ingress Gateway to a service and from one GDCH service to another GDCH service. Each service that runs in GDCH runs as a service account identity with associated cryptographic credentials. When communicating over mTLS through Anthos Service Mesh, GDCH services use client certificates to authenticate to other services. Anthos Service Mesh verifies these certificates using an internal certificate authority. When communicating over TLS, for example, to a GDCH Kubernetes API Server, GDCH services use Kubernetes service account tokens to authenticate to services. Kubernetes service account tokens are verified using the public keys of the Kubernetes API Server token issuer.