How to do a redirect from HTTP to HTTPS with Google Kubernetes Engine Ingress

Google Kubernetes Engine(GKE) Ingress(gce-ingress), as of the date of this article, does not allow you to configure any redirects directly in the ingress.

Until recently you couldn’t even configure the Load Balancer associated to the Ingress to do simple HTTPS redirects.

That functionality was added not long ago, to the Load Balancer itself, but it is not yet supported by the ingress-gce. Check the link for more information: https://issuetracker.google.com/issues/35904733#comment95

There are two ways in which you can overcome this big gap in the GKE Engine Ingress functionality.

Don’t use GKE Ingress-gce

If you can use Ingress NGINX instead of Google’s ingress, you can easily setup redirects via configmaps or directly in the ingress.

The main disadvantage of Nginx ingress is that it only gives you the ability of exposing your services via a single public ip. You can of course overcome that by having multiple ingress controllers with different ingress classes. But honestly, you will make your setup really complicated. When you need multiple ips, one per service, that’s what is good about Google’s Ingress. And that is why I had to use it. So I had to somehow make it work.

There is another way to setup the redirect without the Ingress

I am not going to show you how to use the Google Cloud UI to setup a redirect. I really don’t fancy it. It looks like it would be hard to maintain and completely decoupled from your Kubernetes cluster. We are supposed to create a Load balancer on the fly. What would happen to those redirects if you delete the Ingress/Load Balancer? Eventually Google will add this functionality directly to the ingress. But until that happens, we need another way.

After doing some research on StackOverflow I have gone down the route of setting up the redirect in the pod itself. For my use-case, it wasn’t difficult as the website I am hosting is running in an apache-php container. You can do something similar if you also have an Nginx pod running.

Using Apache ModRewrite with .htaccess redirect rules

However, be careful. Kubernetes and even the GKE LB do a regular health check on your pods to check if your service is alive and healthy using a simple HTTP probe. If you setup a blanket redirect from http to https, e.g. a 301 redirect the probe sees that as a malfunctioning pod and for that reason it will try to restart your Pod.

For that reason I ended up adding an exception for GoogleHC probe and the kubernetes probe(kube-probe), so they do not see any redirect. You can also try to modify the probe…. but I didn’t go that route.

.htaccess
 
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTP_USER_AGENT}  !^GoogleHC\/(.*)$
 RewriteCond %{HTTP_USER_AGENT}  !^kube-probe\/(.*)$
 RewriteCond %{HTTP:X-Forwarded-Proto} !https
 RewriteCond %{HTTP_HOST} !localhost
 RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
 </IfModule>

We create a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: httpd-config
data:
  .htaccess: |
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteCond %{HTTP_USER_AGENT}  !^GoogleHC\/(.*)$
   RewriteCond %{HTTP_USER_AGENT}  !^kube-probe\/(.*)$
   RewriteCond %{HTTP:X-Forwarded-Proto} !https
   RewriteCond %{HTTP_HOST} !localhost
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
   </IfModule>
---

And we map the ConfigMap to the Apache-php container:

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: php
spec:
  template:
    spec:
      containers:
      - name: php
        volumeMounts:
          - name: httpd-config
            mountPath: /var/www/html/.htaccess
            subPath: .htaccess
      volumes:
        - name: httpd-config
          configMap:
            name: httpd-config

We also changed the Dockerfile for apache-php so that Mod_rewrite is enabled.