Feature request: ssl-redirect on gce controller about ingress-gce HOT 45 CLOSED

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

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"

from ingress-gce.

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;
    }
}

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

What is the latest here? Will this ever be implemented or should we give up on GCE ingress as a suitable implementation for production workloads?

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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"]
} 

from ingress-gce.

Need that feature too

It would be nice to have it.

Thanks

from ingress-gce.

@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.

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

Any updates on this?

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

/reopen
/remove-lifecycle rotten

haven't heard that this is fixed...

from ingress-gce.

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

from ingress-gce.

@bowei seems like you need to take action here

from ingress-gce.

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

from ingress-gce.

I chose the latter...

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

Yes, we need this update.

from ingress-gce.

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

tx

from ingress-gce.

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.

from ingress-gce.

@ashish-oyo That is too true

from ingress-gce.

Closing in favor of #1075.

from ingress-gce.