ingress-gce: Cannot Disable HTTP when using managed-certificates. HTTPS + HTTP are both provisioned

Cannot disable HTTP when using managed-certificates

When specifying the annotation kubernetes.io/ingress.allow-http: "false" the ingress still accepts HTTP traffic.

Versions

Kubernetes master/node-kube version: 1.12.7-gke.17 (Note: must be equal to or greater than this version, managed certificates had issues prior to this version see https://github.com/GoogleCloudPlatform/gke-managed-certs/issues/2)

Additional Details:

I also tried (https://github.com/kubernetes/ingress-gce/issues/738#issuecomment-486738549):

Creating an ingress without kubernetes.io/ingress.allow-http: "false".
Verified the ingress was serving HTTPS
Then setting allow-http to "false"

Configuration

apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: api-certifcate
spec:
  domains:
    - example.com
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: "web-static-ip"
    networking.gke.io/managed-certificates: api-certifcate
spec:
  rules:
    - http:
        paths:
          - path: /my-service/*
            backend:
              serviceName: my-service
              servicePort: 8080

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 13
Comments: 33 (11 by maintainers)

Most upvoted comments

Unable to disable HTTP via annotation kubernetes.io/ingress.allow-http: "false" on 1.15.9-gke.12 Hoping for http->https rewrite 🤞 But should this issue be re-opened?

Setheck on Mar 18, 2020

Hi, just tried this fix (allowHttp: false) with cluster version 1.17.5-gke.0 It actually works, in the sense that when I try to send a plain HTTP request, the response is a 404 from GCP backend. Anyway, with this strategy, any sensitive content in a plain HTTP request is actually sent over the internet (e.g. the body of a POST request); I rather expected the server to deny the TCP handshake - i.e. respond immediately with a Connection Reset, in so preventing sending data over the network at all. Do you believe such an improvement is possible?

pgp on May 13, 2020

@jmound So there are a couple things to unpack here:

The underlying issue that caused this issue to be filed has been fixed in #631. If you are not observing that the fix is working, then we can keep this open but otherwise this issue should be closed.
Support for SSL-redirects in GKE Ingress is being tracked in #1075 and we will be providing updates on that issue.

Hope that helps.

rramkumar1 on Apr 29, 2020

Quoting a Googler from the parent issue in Google’s bug tracker I linked above:

We have an Alpha available for HTTP(S) Load Balancing URL Rewrites and Redirects. All Alpha terms apply. You need to be white-listed for the alpha. Please contact your Sales Representative or Account Team for more information.

We are proactively working on collecting feedback for the Alpha and will then open it up for public use without any white-listing.

Help is on its way, unfortunately I am not white-listed and cannot provide any feedback for how good/bad the solution is. If anybody is, please let us know anything that an alpha NDA allows you to.

svachmic on Mar 18, 2020

I think this should be solved as soon as possible, it’s a real shame a security issue of this size is still open… Even without rewrite, disabling http completely should suffice at least for most restricted scenarios

pgp on Mar 18, 2020

@pgp I see, thanks for the clarification. I’ll bring this up with our load balancing teams to see if there is a feature request here (or solution). Until this sort of feature is supported in the upstream load balancing API there is nothing we can do here.

rramkumar1 on May 13, 2020

No, in terms of actual security, http->https redirect is equivalent to the situation I described above, in that my plain HTTP request travels over the network, even if it shouldn’t (the only difference is I receive a 302 response instead of a 404 one, but the concept is the same). Completely blocking the traffic on port 80 can be useful in case some REST API users do not comply with the given specifications (i.e. they deliberately or erroneously use http instead of https for an endpoint). Clearly, the steady-state situation is the same - a user receiving a 404 response will modify its client calls accordingly - but meanwhile some (possibly sensitive or private) data have been travelling in plaintext over the public internet.

pgp on May 13, 2020

The fix(#894) is available in GKE version v1.16.4-gke.25 and above(or Ingress v1.8.2).

skmatti on Apr 29, 2020

@jmound Let me refresh myself on what the exact issue was here and get back to you. Thanks.

rramkumar1 on Apr 24, 2020

@jakebolam Feel free to reopen it, I don’t think this issue should be closed.

jmound on Apr 22, 2020