Secure traffic to GKE

How many time to encrypt data in transit?

Mar 13 · 4 min read

Spoiler alert: no code examples in this article 😊

Securing application traffic, also ref’ed as encrypting data in transit or application communication encryption, is a standard security practice and, almost always, a requirement for any multi-tier application. A common practice is to use SSL / TLS protocols. The implementation should declare the version(s) and cipher(s) of the supported protocol(s).

Cloud native applications are often deployed on Kubernetes, like GKE in Google Cloud (GCP). Although the idea of encrypting data in transit is simple the implementation and operation of it may require considerable investments. It may prove helpful to understand how data in transit is protected by cloud providers. Knowing these details and embracing best practices for the specific cloud provider may save development and maintenance efforts and improve operational efficiency of the application. This post reviews data in transit protection in Google Cloud and how it can be applied to applications that run on GKE.

Encryption in transit

All Cloud providers claim to protect data in transit in one way or another. The details depend on the network topology of the application and a Cloud provider’s networking implementation. Google Cloud protects data in transit by encrypting it imperceptibly to a user. The process is described in the whitepaper and public documentation. In essence every communication that starts inside a physical boundary controlled by Google and is sent to another physical boundary controlled by Google is encrypted (using TLS protocol) regardless of destination or whether the communication goes using Google private network or a network provider infrastructure. It means that a direct connection from a client on the internet to a VM inside GCP has to be encrypted by an application.

Exposing an application hosted on GKE

How does data encryption in transit influence application’s services hosted in GKE? It depends how the services are exposed for access. There are two main methods to expose a service hosted in GKE:

  • Via proxy (Ingress or Envoy) ‒ this method is mainly used to expose services that communicate using HTTP(S) or gRPC communication protocols. The proxy (ingress controller or envoy) is just another application running on the GKE cluster. Often the proxy is exposed behind the L7 HTTP(S) load balancer.
  • Direct access ‒ a service is exposed using a cluster’s node IP and port tuple. Like with proxy, the node IP can be accessed directly or ‘hidden” behind the TCP/UDP load balancer.

When using a proxy the data from a client to a service is sent across 3 connections: (1) a connection from a client to Google L7 LB, then (2) from the LB to ingress controller in GKE cluster, and (3) from the controller to one of the Kubernetes pods that runs the application service. It happens because both Google L7 LB and ingress controller work as reverse proxies.

According to the definition, Google Cloud does not encrypt connection 1 communication (blue arrows). Even if a caller is “inside GCP” the communication is routed to a public IP address of the Google load balancer and is not a subject of the default protection in transit. The connection 2 (grey arrow) is always encrypted by Google even if you configure LB to communicate to the backend service over HTTPS/SSL. The connection 3 would be implicitly encrypted only if the ingress controller and the application service run in different availability zones since the different availability zones are always hosted in the different physical locations.

For direct access the connection is established between a client on the internet and a VM in GCP. It matches the connection 1 in the diagram above. As explained in the previous paragraph, Google does not implicitly encrypt these connections. The encryption has to be implemented by the application.

When to encrypt?

Leaving aside the careless option, there are two main approaches:

  • Secure application traffic from MitM attacks
  • Follow regulated encryption policies

For regulated applications there is no choice but to encrypt all connections. Otherwise, it is sufficient to encrypt only connection 1 leaving to the cloud provider (Google in this case) hard work to encrypt traffic in transit within the cloud premises.


The above is an overview of the traffic encryption principles in Google Cloud Platform. This article is not guidelines for security. If you need one, consider calling to the GCP professional services.

Google Cloud - Community

Google Cloud community articles and blogs


Written by


Cloud Engineer in PSO at Google, Specializing in Infrastructure, AppDev, Security and SRE. Horsemanship in a free time.

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store