Do you encrypt traffic between GKE nodes and external Load balancers?

Question

I have a GKE standard deployment in GCP. I have TLS terminating at an IAAS managed load balancer, provided by their Ingress controller. The certificates are GoogleManagedCertificates. I'm fine with traffic past the load balancer and traffic within the cluster.

But what about traffic from the load balancer to the GKE NodePort? Although this traffic is within the Google network, this is technically public traffic. And it's currently unencrypted. While trying to add a (valid) certificate for the service behind the load balancer, it blurred the responsibilities between the load balancer and service. To be fair, there is a firewall rule to permit communication between these 2.

What are best practices here?

• Leave things as is?
• Set up another round of TLS termination for every exposed k8s service?
• Is there a simple way to get the google managed load balancer to communicate via private IP?

Here's a diagram:

Answer 1

If you're looking for "best" security practice here, it's (at a generic level) going to recommend encrypting the traffic between the local balancer and nginx ingress, as security best practice tends to be "encrypt all the things"!.

Whether that's actually worth it, for your use case, is another matter. The risk you would be mitigating with this additional control is reducing the risk of a Man-In-The-Middle attack between the load balancer and reverse proxy.

In the question you mention that this is a google managed network, so your question is are you concerned that either a) google are malicious and seeking to attack your environment or b) Google will suffer an attack which will allow an attacker to MITM traffic in your environment.

For a) I'd suggest that, if your threat model includes the CSP being malicious, you're better off not running in that cloud as there's a wide variety of ways for them to compromise you.

For b), that's a risk decision. Essentially weighing up the extra work of the control and possible problems it introduces (e.g. managing certificate rotation) against the perceived risk.

One additional consideration would be if you have any compliance concerns. If your environment is subject to a standard that requires that all traffic is encrypted in transit, it's likely going to be easier to implement the control than try to get an exception from the standard.