Feature request: ssl-redirect on gce controller

[bowei]

From @smeruelo on August 18, 2017 15:1

Is there any plan to support ingress.kubernetes.io/ssl-redirect annotation on gce controller?

If not, what's the recommended workaround for this? Examining headers is not always possible, since backend application is often out of our control.

Copied from original issue: kubernetes/ingress-nginx#1180

[bowei]

From @hatemosphere on August 24, 2017 15:17

i would not expect it to work it any time soon. here is feature request for https redirection and it's almost 2 years old https://issuetracker.google.com/issues/35904733
and i don't think it's possible without examining the headers. you can always switch to alternative ingress controller though.

[bowei]

From @tonglil on September 14, 2017 1:55

Another workaround is to run a proxy between GCLB and your app that checks the x-forwarded-proto header for https and redirects if it is http.

Or you can implement this in your app.

This is a pretty commonly implemented header by most load balancers/cdns to identify client->proxy/lb connections. It will look like this:

x-forwarded-proto=http
// or
x-forwarded-proto=https

---

In either case (workaround or some GCP solution), the request has already transmitted the data in plaintext over the internet so if that initial request had any sensitive data, it could already be sniffed.

If you don't want that, you can use this GCE Ingress annotation to disable requests to port 80 completely:

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

[drgomesp]

Any updates on this?

[nicksardo]

Best to track the the issue linked by hatemosphere: https://issuetracker.google.com/issues/35904733. Nothing can be done in this controller until it's supported upstream.
/unassign

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[tonglil]

For interested parties, please also look at https://googlecloudplatform.uservoice.com/forums/302616-load-balancing/suggestions/31951531-allow-http-to-redirect-to-https-automatically.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[matohl]

Amazing this is not implemented yet, it is a basic required functionality in a load balancer 2018. Even more amazing since Google is trying to push the web in the secure direction : https://www.theverge.com/2018/2/8/16991254/chrome-not-secure-marked-http-encryption-ssl

[hnykda]

Totally agree. It is ridiculous. Is there anything one could do to make this happen? Any open source project which could unblock this? It's the most wanted feature by an order of magnitude and nothing has been happening for ages.

[WhileLoop]

Using nginx ingress controller seems to be the best work around at the moment.

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[dargmuesli]

/reopen
/remove-lifecycle rotten

haven't heard that this is fixed...

[k8s-ci-robot]

@dargmuesli: you can't re-open an issue/PR unless you authored it or you are assigned to it.

In response to this:

/reopen
/remove-lifecycle rotten

haven't heard that this is fixed...

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[emasyakin]

it's not rotten, it's still important to do

[dargmuesli]

@bowei seems like you need to take action here

[RobMaskell]

@bowei please can you reopen this ticket, it seems no one else can and it's important to some of us

[matt0x6F]

Since the Google Issue Tracker issue is now dead I think it's a good time remind everyone that Chrome has now declared all HTTP websites as "not secure".

https://www.eff.org/deeplinks/2018/07/google-chrome-now-marks-http-sites-not-secure

I propose that the prioritization of this issue be bumped accordingly to avoid causing pain and confusion to end users who don't understand what "not secure" actually means in this context.

[bowei]

Hi sorry, this issue should be frozen, sorry about it falling into the rotten status.

[mike-marcacci]

This would certainly be a nice feature, given how common a pattern it is... but I must say it's not exactly difficult to accomplish other ways.

If you have few backends, you can simply read the X-Forwarded-Proto header and reply with a 301 on "http".

If your backends are unable to do this (or you'd rather have a cleaner separation of responsibilities), you can create one ingress that terminates HTTPS and forwards requests to your production backends; and another that listens on HTTP and simply returns a 301. Isn't this the idiomatic solution within a microservice architecture (which is what k8s promotes in the first place)?

I wouldn't be surprised if this feature was never addressed, given the available solutions... but I think it would be helpful if the documentation were updated with a recommended solution, so this would look less like a glaring omission.

[RobMaskell]

I wonder if it was booked by this https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing and now maybe, finally it will be addressed

[necevil]

The one thing I would love to see here (given that we are currently using kube mci — for multi-region load balancing on GKE which in turn relies on GCE-Ingress) is better documentation on how to run nGinx Ingress internally behind a GCE-Ingress. I haven't found anything on this other than people say it's possible.

That said obviously (in my case) having 301s in GCE-Ingress would solve the entire issue meaning I don't need to worry about other services (and ingresses) behind GCE-Ingress.

[FearlessHyena]

Any news on this from Google? At least a roadmap or some indication this is being worked on would be nice :)

[onixmatt]

This would be a very nice feature to have built in. Another option is to also use Istio, but again it feels like a workaround for something that shouldn't even be a problem.

[Akuka]

We are in 2019, will we see this feature soon or should I come back in 2020?

[bowei]

As ingress-gce exposes the underlying GCLB functionality, as commented before, please vote for the feature in GCLB: https://googlecloudplatform.uservoice.com/forums/302616-load-balancing/suggestions/31951531-allow-http-to-redirect-to-https-automatically

[ajainvivek]

This is an essential feature. I don't understand, why this isn't prioritised for so long.

[ThanhTuNguyen]

Yes, we need this update.

[savicprvoslav]

This is a bit of a problem and support ( or solution ) for this must be added.

tx

[mercuriete]

Need that feature too

It would be nice to have it.

Thanks

[fazpu]

I poured hours into learning gke controller and then stumbled upon this issue - the technology is unusable without the feature.

[jim5359]

Why is this so hard for a web company to prioritize and implement?

[fazpu]

For anyone, who is looking for working solution to the redirect problem, this is a simplified conf file imported to the /etc/nginx/conf.d in the nginx docker to which the ingress is pointing:

server {
    listen          80;
    server_name     example.com www.example.com;

    keepalive_timeout  620s;

    if ($http_x_forwarded_proto = "http") {
        rewrite          ^ https://$server_name$request_uri? permanent;
    }

    location / {
        root /srv/angular/app;

        try_files $uri$args $uri$args/ $uri $uri/ /index.html;
    }
}

[mercuriete]

In my company we use this
https://github.com/RealKinetic/http-to-https

But the question is not how to workaround the problem.
The question is a feature request to support a kubernetes annotation that should be implemented in the first place.

[ricardocamposilva]

Disappointing that google doesn't look at this as a critical feature, even the worst LB has this feature.

[ashish-oyo]

Disappointing. HTTPS redirection and adding HTTPS support is so difficult in GKE. That's why AWS is leading the market.

[Rukeith]

@ashish-oyo That is too true

[thuandt]

Google is working on it, expect alpha in 2019Q4 :) (see uservoice links)
https://googlecloudplatform.uservoice.com/forums/302616-load-balancing/suggestions/31951531-allow-http-to-redirect-to-https-automatically

[carloruiz]

I followed @mike-marcacci 's suggestion and it works quite nicely. I can still leverage the nice features of GKE Ingress while redirecting http. The following code is terraform, hence the syntax.

This is the mains service, where I force http.

resource "kubernetes_ingress" "console" {
  metadata {
    name = "console"

    annotations = {
      "kubernetes.io/ingress.allow-http"            = "false"
      "ingress.gcp.kubernetes.io/pre-shared-cert"   = var.console_ssl_cert
      "kubernetes.io/ingress.global-static-ip-name" = var.console_address_kubernetes_name 
    }
  }

  spec {
    rule {
      http {
        path {
          path = "/"
          backend {
            service_name = "console"
            service_port = "80" 
          }
        }
      }
    }
  }
}

This is a simple redirect service I wrote up my self that returns 301.

resource "kubernetes_ingress" "redirect" {
  metadata {
    name = "redirect"

    annotations = {
      "kubernetes.io/ingress.global-static-ip-name" = var.console_address_kubernetes_name
    }
  }

  spec {
    rule {
      http {
        path {
          backend {
            service_name = "redirect"
            service_port = "80" 
          }
        }
      }
    }
  }
  depends_on = ["kubernetes_service.redirect"]
} 

[codefist]

one of the only features that the everyday man needs in his ingress controller and fucking GOOGLE doesn't have it?!

[SeriousAnt]

We are in 2019, will we see this feature soon or should I come back in 2020?

May be in 2021 :( Seriously Google, would love to find out why this essential feature hasn't been implemented in the ingress controller. Take some inspiration from AWS

[mercuriete]

@SeriousAnt if you read this:
https://issuetracker.google.com/issues/35904733

They are already on closed alpha for load balancing.
I am looking forward like you.

Maybe this feature became general available this year and maybe as you said in 2021 will be Alpha for GKE.

By the way It would be nice to know how i can join for the Alpha load balancer.

[bkw]

I think this can be closed in favour of #1075. Or the other way around.

[rramkumar1]

Closing in favor of #1075.