Secure traffic to GKE
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.