How to expose GKE TCP services with SSL termination at cluster edge and client cert auth

Question

I'm looking for a generic way to expose multiple GKE TCP services to the outside world. I want SSL that's terminated at cluster edge. I would also prefer client certificate based auth, if possible.

My current use case is to access PostgreSQL services deployed in GKE from private data centers (and only from there). But basically I'm interested in a solution that works for any TCP based service without builtin SSL and auth.

One option would be to deploy an nginx as a reverse proxy for the TCP service, expose the nginx with a service of type LoadBalancer (L4, network load balancer), and configure the nginx with SSL and client certificate validation.

Is there a better, more GKE native way to achieve it ?

Answer 1

To the best of my knowledge, there is no GKE-native way to achieve exactly what you need.

If this was only dealing with HTTP-based traffic, you could simply use GKE Ingress for HTTP(S) Load Balancing but taking into consideration:

But basically I'm interested in a solution that works for any TCP based service without builtin SSL and auth.

this is not your use case.

So you can either stay with what you've already set up as it seems to work well or as an alternative you can use:

1. ✅ nginx ingress, which unlike GKE ingress is able to expose to the external world not only HTTP/HTTPS-based traffic, but also can proxy TCP connections coming to arbitrary ports.

2. ✅ You can use TLS termination proxy as a sidecar (something like this one or this one) behind External TCP/UDP Network Load Balancer. As it is not a proxy but a pass-through LB, it cannot provide SSL termination and will only be able to pass the encrypted TCP traffic to the backend Pod where it needs be handled by the above mentioned sidecar.

3. ❌ From the GCP-native load balancing solutions presented in this table only SSL Proxy may seem useful at first glance as it can handle TCP traffic with SSL offload, however ❗it supports only limited set of well-known TCP ports and as far as I understand, you need to be able to expose arbitrary TCP ports so this won't help you much:

SSL Proxy Load Balancing support for the following ports: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, and 9300. When you use Google- managed SSL certificates with SSL Proxy Load Balancing, the frontend port for traffic must be 443 to enable the Google-managed SSL certificates to be provisioned and renewed.