How to force SSL for Kubernetes Ingress on GKE

SslKubernetesGoogle Kubernetes-EngineKubernetes Ingress

Ssl Problem Overview


Is there a way to force an SSL upgrade for incoming connections on the ingress load-balancer? Or if that is not possible with, can I disable port :80? I haven't found a good documentation pages that outlines such an option in the YAML file. Thanks a lot in advance!

Ssl Solutions


Solution 1 - Ssl

https://github.com/kubernetes/ingress-gce#frontend-https

You can block HTTP through the annotation kubernetes.io/ingress.allow-http: "false" or redirect HTTP to HTTPS by specifying a custom backend. Unfortunately GCE doesn't handle redirection or rewriting at the L7 layer directly for you, yet. (see https://github.com/kubernetes/ingress-gce#ingress-cannot-redirect-http-to-https)

Update: GCP now handles redirection rules for load balancers, including HTTP to HTTPS. There doesn't appear to be a method to create these through Kubernetes YAML yet.

Solution 2 - Ssl

This was already correctly answered by a comment on the accepted answer. But since the comment is buried I missed it several times.

As of GKE version 1.18.10-gke.600 you can add a k8s frontend config to redirect from http to https.

https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features#https_redirect

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: ssl-redirect
spec:
  redirectToHttps:
    enabled: true

# add below to ingress
# metadata:
#   annotations:
#     networking.gke.io/v1beta1.FrontendConfig: ssl-redirect

Solution 3 - Ssl

The annotation has changed:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
...

Here is the annotation change PR: https://github.com/kubernetes/contrib/pull/1462/files

Solution 4 - Ssl

If you are not bound to the GCLB Ingress Controller you could have a look at the Nginx Ingress Controller. This controller is different to the builtin one in multiple ways. First and foremost you need to deploy and manage one by yourself. But if you are willing to do so, you get the benefit of not depending on the GCE LB (20$/month) and getting support for IPv6/websockets.

The documentation states:

> By default the controller redirects (301) to HTTPS if TLS is enabled for that ingress . If you want to disable that behaviour globally, you > can use ssl-redirect: "false" in the NGINX config map.

The recently released 0.9.0-beta.3 comes with an additional annotation for explicitly enforcing this redirect:

> Force redirect to SSL using the annotation ingress.kubernetes.io/force-ssl-redirect

Solution 5 - Ssl

Google has responded to our requests and is testing HTTP->HTTPS SSL redirection on their load balancers. Their latest answer said it should be in Alpha sometime before the end of January 2020.

Their comment: >Thank you for your patience on this issue. The feature is currently in testing and we expect to enter Alpha phase before the end of January. Our PM team will have an announcement with more details as we get closer to the Alpha launch.

My fingers are crossed that we'll have a straightforward solution to this very common feature in the near future.


UPDATE (April 2020):

HTTP(S) rewrites is now a Generally Available feature. It's still a bit rough around the edges and does not work out-of-the-box with the GCE Ingress Controller unfortunately. But time will tell and hopefully a native solution will appear.

Solution 6 - Ssl

A quick update. Here

Now a FrontEndConfig can be make to configure the ingress. Hopes it helps.

Example:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: 301

You'll need to make sure that your load balancer supports HTTP and HTTPS

Solution 7 - Ssl

Worked on this for a long time. In case anyone isn't clear on the post above. You would rebuild your ingress with annotation -- kubernetes.io/ingress.allow-http: "false” -- Then delete your ingress and redeploy. The annotation will have the ingress only create a LB for 443, instead of both 443 and 80.

Then you do a compute HTTP LB, not one for GKE.

Gui directions: Create a load balancer and choose HTTP(S) Load Balancing -- Start configuration.

choose - From Internet to my VMs and continue

Choose a name for the LB

leave the backend configuration blank.

Under Host and path rules, select Advanced host and path rules with the action set to Redirect the client to different host/path. Leave the Host redirect field blank. Select Prefix Redirect and leave the Path value blank. Chose the redirect response code as 308. Tick the Enable box for HTTPS redirect.

For the Frontend configuration, leave http and port 80, for ip address select the static IP address being used for your GKE ingress.

Create this LB.

You will now have all http traffic go to this and 308 redirect to your https ingress for GKE. Super simple config setup and works well.

Note: If you just try to delete the port 80 LB that GKE makes (not doing the annotation change and rebuilding the ingress) and then adding the new redirect compute LB it does work, but you will start to see error messages on your Ingress saying error 400 invalid value for field 'resource.ipAddress " " is in use and would result in a conflict, invalid. It is trying to spin up the port 80 LB and can't because you already have an LB on port 80 using the same IP. It does work but the error is annoying and GKE keeps trying to build it (I think).

Solution 8 - Ssl

Thanks to the comment of @Andrej Palicka and according to the page he provided: https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features#https_redirect now I have an updated and working solution.

First we need to define a FrontendConfig resource and then we need to tell the Ingress resource to use this FrontendConfig.

Example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-app-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: myapp-prd
    networking.gke.io/managed-certificates: managed-cert
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/v1beta1.FrontendConfig: myapp-frontend-config
spec:
  defaultBackend:
    service:
      name: myapp-app-service
      port:
        number: 80
---
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: myapp-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: MOVED_PERMANENTLY_DEFAULT

Solution 9 - Ssl

You can disable HTTP on your cluster (note that you'll need to recreate your cluster for this change to be applied on the load balancer) and then set HTTP-to-HTTPS redirect by creating an additional load balancer on the same IP address.

I spend couple of hours on the same question, and ended up doing what I've just described. It works perfectly.

Solution 10 - Ssl

Redirecting to HTTPS in Kubernetes is somewhat complicated. In my experience, you'll probably want to use an ingress controller such as Ambassador or ingress-nginx to control routing to your services, as opposed to having your load balancer route directly to your services.

Assuming you're using an ingress controller, then:

  • If you're terminating TLS at the external load balancer and the LB is running in L7 mode (i.e., HTTP/HTTPS), then your ingress controller needs to use X-Forwarded-Proto, and issue a redirect accordingly.
  • If you're terminating TLS at the external load balancer and the LB is running in TCP/L4 mode, then your ingress controller needs to use the PROXY protocol to do the redirect.
  • You can also terminate TLS directly in your ingress controller, in which case it has all the necessary information to do the redirect.

Here's a tutorial on how to do this in Ambassador.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSimon HeinzleView Question on Stackoverflow
Solution 1 - SslPrashanth BView Answer on Stackoverflow
Solution 2 - SslGeorge BView Answer on Stackoverflow
Solution 3 - SslmlazarovView Answer on Stackoverflow
Solution 4 - SslFabian DörkView Answer on Stackoverflow
Solution 5 - SslJoshView Answer on Stackoverflow
Solution 6 - SslDiego ConversView Answer on Stackoverflow
Solution 7 - SslMBarView Answer on Stackoverflow
Solution 8 - SslDaniel ViguerasView Answer on Stackoverflow
Solution 9 - SslOmri GivoniView Answer on Stackoverflow
Solution 10 - SslRichard LiView Answer on Stackoverflow