How to set up HTTPS with Istio and Kubernetes on GKE

You would typically use annotations on Kubernetes ingress to set up HTTPS and static IP with GKE. Istio set up its own ingress load balancer which is of type ‘Service’ but GKE is not compatible with annotations of that type.

If you are not familiar with Kubernetes you can check out this article or if you want to live test this article setup your own Kubernetes cluster on GKE by following this article.

Cert-Manager with Kubernetes and GCP

You can use cert-manager with Kubernetes to set up HTTPS, the process is fairly straightforward. We’ll go through setting it up.

1. Setup Istio to work with cert-manager

2. Setup certificate, make sure to set all env variables

3. Done!

 

If you require a production level certificate you can change the issuerRef name to letsencrypt instead of letsencrypt-staging

For more details on this setup you can go see their official documentation

And cert-manager documentation.

 

Pros & cons of this solution:

Pro

Con

Easy to set up

Does not use managed certificates from cloud provider

All traffic secured with TLS

Relies on SDS to reload certificate and secrets

Setup Istio with Managed HTTPS certificate from GCP

If you do not want to use cert-manager with Kubernetes to set up HTTPS. You can use managed certificate directly from your favourite cloud provider

With GKE this is managed with annotations on the Kubernetes ingress level. Unfortunately, annotations and istio ingress aren't compatible because istio ingress-gateway is a type ‘Service’, thus setting it up requires a bit of configuration.

You can set up an ingress as a load balancer type (default in GCP) that forwards traffic to the istio ingress gateway. 

The issue with this is that the load balancer health checks won’t succeed because they will be directed to port 80 of the istio-ingressgateway on the root path ‘/’. This health check configuration is enforced by Kubernetes and thus can not be modified.  

The problem is that the health check for Istio-ingressgateway run on port 15020 on the /healthz/ready path. To work around this you will need to set up a virtual service that rewrites google health checks to istio-ingressgateway:15020/healthz/ready

The following scheme explains this setup:

Istio & HTTPS

 

Step by step guide

To configure this in your Kubernetes cluster you will need to configure Istio in NodePort configuration (Default is load balancer)

Check out this code to set it up with helm here : 

Then we need to set up the certificate, ingress and the redirection for load balancer health check.

  • Managed certificate
  • An ingress 
  • A Gateway to receive incoming traffic from the ingress gateway
  • A virtual service

You should green all through the board! 

 

Pros & cons of this solution:

Pro

Con

Certificate managed by cloud provider

A bit of set up required

 

Traffic between ingress and ingress gateway not secured with TLS

 

If you want to use cert-manager or you would rather use a managed certificate from your favourite cloud provider, istio can be configured and can get a production ready HTTPS.

You can find here the required configuration for Kubernetes on AWS.

Benjamin Sanvoisin

Benjamin Sanvoisin

Benjamin is a Site Reliability Engineer at Padok

What do you think? Leave your comments here !