HTTP to HTTPS redirection

[Cyral]

Now that GCP Load Balancers finally have HTTP to HTTPS redirection support, can this be configured through YAML so redirection is handled by GCP and not the application?

[mercuriete]

I think this is a duplicated of #51 and not the other way round.

[rramkumar1]

cc @spencerhance who is working on integrating this into GKE Ingress.

[hypery2k]

any news on this?

[mark-church]

Yes we are currently working on this. It's currently in development so we don't have a committed timeline yet. We will update this thread as development gets closer to completion and we can provide a realistic estimate.

[thaniyarasu]

Can we get an approximate date for this fix into ingress-gce yaml

[mo4islona]

+1

[halradaideh]

@thaniyarasu can the GKE ingress have this feature ?

like annotation or something like that ? to redirect from HTTP to HTTPS

[m-tanner]

+1

[dconvers1979]

+1

[clenn]

+1

[sp185503]

@thaniyarasu can the GKE ingress have this feature ?

like annotation or something like that ? to redirect from HTTP to HTTPS

Ideally this would be the preferred way to use this feature, via annotation.

[mark-church]

Hi All, here's a quick update on where we stand with HTTPS redirects for GKE Ingress:

• It's still in development
• It will be implemented via a boolean enable/disable for the entire Ingress resource (using FrontendConfig as a CRD to hold structured config for frontend load balancer policy)
• We're targeting Q3 for a release to GKE

[sp185503]

Hi All, here's a quick update on where we stand with HTTPS redirects for GKE Ingress:

• It's still in development
• It will be implemented via a boolean enable/disable for the entire Ingress resource (using FrontendConfig as a CRD to hold structured config for frontend load balancer policy)
• We're targeting Q3 for a release to GKE

Good to hear, thanks for sharing.

[m-tanner]

Just out of curiosity (not rushing!), will it be available towards the beginning or end of Q3?

[geun]

1206 Implement support for HTTPS Redirects

finally!! It's coming. I'm really waiting for this features.

[icco]

Now that #1206 has been merged, what's the rollout process look like?

[spencerhance]

Hi @icco,

This should be rolling out to the GKE Rapid channel within the next two weeks. It will be at least 2-3 weeks after that before you will see it in the GKE Regular channel. I will post an update here as soon as we officially launch 🚀 .

[hadim]

That's great news.

How the redirection will be specified? In the Ingress spec within metadata.annotations? Something like this:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: app-remote-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: app-gcp-ip
    networking.gke.io/managed-certificates: app-certificate
    networking.gke.io/RedirectToHttps: PERMANENT_REDIRECT
spec:
  backend:
    serviceName: app-server-remote
    servicePort: 7777

[iagomelanias]

From #1206, it's possible to determine that the configuration is very similar to SSL Policies, as it uses the same resource kind FrontendConfig. @spencerhance explained how to use them in this comment.

I believe it would be something like this:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: test-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: PERMANENT_REDIRECT # possible values are: FOUND, TEMPORARY_REDIRECT, PERMANENT_REDIRECT, looks like the default is PERMANENT_REDIRECT

And the Ingress resource must have the following annotation.

networking.gke.io/v1beta1.FrontendConfig: test-frontend-config

@spencerhance is it correct?

[ncoonrod]

@iagomelanias that redirectToHttps object isn't working for me on a GKE 1.17.9-gke.6300 cluster. I'm using networking.gke.io/v1beta1 as well. According to the docs at https://pkg.go.dev/k8s.io/ingress-gce/pkg/apis/frontendconfig/v1beta1 It looks like it should?

Here's how mine looks:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: httpRedirect
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: PERMANENT_REDIRECT

When I try to deploy it, it says redirectToHttps doesn't exist.

[tvvignesh]

@spencerhance Any relation between GKE version and GCE ingress version? I have been looking at Rapid channel release notes since it is expected to arrive soon. But, not sure which version of GCE ingress is included with it. For instance, this was released 2 days ago and I am not able to see a release note for GCE ingress there: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md#v1189 . Or did I miss something?

[GeckoSplinter]

Indeed It's hard to match the ingress-GCE version with a GKE version.

My point of reference is here : https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features You can see that there is no mention of redirect https in the FrontendConfig part yet.

[spencerhance]

Hi @tvvignesh We have still not officially released this in GKE unfortunately. This is currently available in all Ingress-GCE 1.10 versions.

@iagomelanias that setup looks correct.

[tibers]

fix plzzzzzzzz I am doing a deployment call right now and they just asked about this.

[smarkwell]

fix plzzzzzzzz I am doing a deployment call right now and they just asked about this.

As someone who is also still waiting for this solution, the work around I have in place today (without spinning up some insane nginx/haproxy/httpd stack inside my cluster) is to stop listening to http on my k8s cluster.

kubernetes.io/ingress.allow-http: "false"

Then you are free to setup an entirely separate load balancer at google, on the same IP address that does nothing but listen on port 80 and return permanent redirect (or your preference) to port 443.

• https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-xlb#disabling_http
• https://cloud.google.com/load-balancing/docs/https/setting-up-http-https-redirect#partial-http-lb

(As someone who has worked with Apache HTTPd/HAProxy/BigIP F5 LTM, this does irk me and I am looking forward to GCE supporting this directly)

[sdrush-mw]

Yeah, we have hit upon the same solution - enabling a separate compute engine load balancer on the the same frontend IP port with no backends just firing redirects, but it boggles the mind that a simple feature that has been on the GLB for 6 months STILL is not available in GKE.

[dinvlad]

Another solution here is a bucket backend which serves a redirect page.

[spencerhance]

@spencerhance Any relation between GKE version and GCE ingress version? I have been looking at Rapid channel release notes since it is expected to arrive soon. But, not sure which version of GCE ingress is included with it. For instance, this was released 2 days ago and I am not able to see a release note...

Hi @tvvignesh,

Typically we tag releases in open source and soak them internally before we release them in GKE. We usually update the changelog here https://github.com/kubernetes/ingress-gce#gke-version-mapping when an image is officially released in GKE. Sometimes the images are released in rapid before we officially launch a feature and update the docs :)

[pdecat]

Quick question: why is v1.18.0 still referenced as latest while that version is not even in the version mapping list?

https://github.com/kubernetes/ingress-gce/releases/latest redirects to https://github.com/kubernetes/ingress-gce/releases/tag/v1.8.0

[spencerhance]

@pdecat That is an error, we have unfortunately not kept our releases and tags in sync: https://github.com/kubernetes/ingress-gce/issues/1216

[tvvignesh]

Thanks @spencerhance for the clarification. Will wait (even if its going to be an "unofficial" release 😉)

[obedtandadjaja]

@spencerhance Excited about this feature, is there an ETA for it?

[dldereklee]

Is there a chance this will work with internal ingress in the future?

[hadim]

I have also tested the following config:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: argo-remote-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: MOVED_PERMANENTLY_DEFAULT  # 301 code

but once applied, k8s says the configuration is invalid. If I force the deployment without validation nothing happens on the LoadBalancer.

I am using GKE 1.17.12-gke.1504. Not sure at which application-level this feature is deployed since the release notes (https://cloud.google.com/kubernetes-engine/docs/release-notes#november_13_2020) says nothing about GKE/k8s version.

[anderspetersson]

@hadim Looks like you need 1.18.10+600 https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features

[hadim]

Thanks, @anderspetersson. Somehow I missed it.

[spencerhance]

Hey Folks, this is now available in 1.18.10-gke.600+! Thank you all for your patience. We also have already planned support in 1.17 and are targeting end of this month.

[mark-church]

This tutorial has an example of managed certs, SSL Policy, and HTTPS redirects together in an Ingress which might be helpful as well!

[pgp]

Hi, any news about the possibility of completely disabling plain HTTP (a.k.a. not exposing port 80 at all) from ingress settings? There had been some discussion in this other issue but I don't know if this has been taken into account as possible feature.

[mehdicopter]

Yes @pgp you can. Take a look here : https://cloud.google.com/kubernetes-engine/docs/concepts/ingress-xlb#disabling_http

[pgp]

I am already using the annotation: kubernetes.io/ingress.allow-http: "false" in my configuration, however that doesn't translate in a low-level disable, but only application-level (i.e. gcp responds with a 404, instead of the browser showing a Connection reset message, which is what I would expect if port 80 on the ingress was totally blocked)

[boredabdel]

@pgp How does your ingress spec looks like ?

[pgp]

here it is (clearly, I've removed runtime annotations added by GKE, and anonymized resource names):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: my-global-static-ip-resource-name
    networking.gke.io/managed-certificates: my-managed-cert-resource-name
  creationTimestamp: "2020-05-15T00:00:00Z"
  finalizers:
  - networking.gke.io/ingress-finalizer-V2
  generation: 7
  name: my-ingress-resource-name
  namespace: default
spec:
  rules:
  - host: my.public.domain.com
    http:
      paths:
      - backend:
          serviceName: my-first-service
          servicePort: 59999
        path: /first/*
        pathType: ImplementationSpecific
      - backend:
          serviceName: my-second-service
          servicePort: 80
        path: /*
        pathType: ImplementationSpecific
status:
  loadBalancer:
    ingress:
    - ip: 12.34.56.78

[boredabdel]

Yeah i have a similar ingress with allow-http set to false and my browser shows 404. That's the expected behavior for GCLB.

[pgp]

Indeed, also my ingress sends a 404 as response in that case. My question was about the possibility of totally disabling port 80, instead of sending the request in cleartext using the wrong protocol and then receiving a 404 as response.

[boredabdel]

So the 404 is returned from the LoadBalancers, it doesn't reach your application. Your browser send a request to the IP:80, it's gets to the loadBalancing layer which reply as 404 (aka we don't know what is this). You cannot disable 80 completely.

[pgp]

So, this is a limitation of the load balancer, and not of the ingress resource...

[allenvino1]

Any news in supporting this in 1.17? :)

[dconvers1979]

Here is an update: here

[cport1]

Here is an update: here

FINALLY!