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)

[boredabdel]

@Cyral Yes your new Ingress will have to have a different name than the existing one, Kubernetes will not allow you to create two objects of the same Kind in the same namespace with identical names.

An other Option is to run two clusters with Multi Cluster Ingress, have a single VIP attached to the DNS record your customers use and failover the clusters to do maintenance on your clusters. You can find few examples on how to do that here [1]

[1]https://github.com/GoogleCloudPlatform/gke-networking-recipes/tree/master/multi-cluster-ingress

[spencerhance]

@boredabdel

MultiClusterIngress is great! However one of the drawbacks is that it doesn't support HTTPS Redirects yet. This is changing very soon though :)

[boredabdel]

Yes correct. We are working on it :) @mark-church FYI

[red8888]

Is this supported for private ingresses? I get this error: does not exist: ensureRedirectUrlMap() = error: cannot enable HTTPS Redirects with L7 ILB

[boredabdel]

@red8888 The frontendConfig CRD is not supported with Internal HTTP(s) LB. Have a look at this page [1] which contains the compatibility matrix between features and the various types of loadBalancers

[1]https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features

[gaurav517]

@boredabdel

MultiClusterIngress is great! However one of the drawbacks is that it doesn't support HTTPS Redirects yet. This is changing very soon though :)

Eagerly waiting for this feature. Is there any suggested approach documented somewhere for HTTS redirects in multi-cluster ingress? Thanks.

[boredabdel]

@gaurav517 you can do the http->https redirect in your app. Or maybe run a simple proxy which will redirect http calls to the LB and proxy https directly to your app. I have never done this before so to be tested

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[kamalmarhubi]

/remove-lifecycle stale

[boredabdel]

@gaurav517 FrontendConfig for MCI is GA now. I just finished documenting an example here https://github.com/GoogleCloudPlatform/gke-networking-recipes/pull/68/files.

Once merged (hopefully today) it will go under https://github.com/GoogleCloudPlatform/gke-networking-recipes/tree/master/ingress/multi-cluster/mci-frontend-config

This recipe contains an example of HTTP to HTTPS redirect with MCI and SSL-Policies at the LB Level.

Hope this helps. Let us know in the gke-network-recipes repo if you have any issues. Suggestions ;)

[boredabdel]

One last update and we can probably close this one for good as it have been going on for a while ;)

We are actively working on https://github.com/GoogleCloudPlatform/gke-networking-recipes.

Feedback is appreciated it ;)

[Gageperrin]

@boredabdel this is coming just in the nick of time for a project I'm working on. Having trouble getting it to work using the provided example.

Let me know if I should start a new issue, but I'll post the info here.

The FrontEnd Config annotation in the Ingress YAML creates what appears in the console menu as a HTTP(S) load balancer but only has a single HTTP front-end with no certificate or SSL policy attached, despite these being annotated in the Ingress YAML. the SSL cert is stuck in provisioning as FAILED_NOT_VISIBLE.

If I understand correctly from the docs here, two load balancers should be provisioned, one HTTP and one HTTPS. The HTTP should redirect to the HTTPS. Instead, one HTTP load balancer is created with the original Ingress backends.

The HTTP Load Balancer reports the original HTTP backends as healthy while the Ingress reports its backend services as "Unknown".

Is there something wrong with syntax or spec that is preventing the HTTPS Load Balancer from generating correctly?

The HTTP LB worked fine before the frontend config was added, but I want to force HTTPS.

FrontEnd Config YAML:

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: api-ingress-frontend-config
  namespace: default
spec:
  sslPolicy: ssl-policy <--- externally created
  redirectToHttps:
    enabled: true

Here are the in-console annotations for the Ingress after it has finished creating.

ingress.kubernetes.io/backends: {"k8s-be-32127--eec1f12e1a4cdd9a":"Unknown","k8s1-eec1f12e-default-my-api-service-8000-eec5eed4":"Unknown"}
ingress.kubernetes.io/forwarding-rule: k8s2-fr-phd59a9z-default-my-ssl-ingress-gx4lonad
ingress.kubernetes.io/target-proxy: k8s2-tp-phd59a9z-default-my-ssl-ingress-gx4lonad
ingress.kubernetes.io/url-map: k8s2-um-phd59a9z-default-my-ssl-ingress-gx4lonad
kubernetes.io/ingress.class: gce
kubernetes.io/ingress.global-static-ip-name: ip-my-api-ingress
networking.gke.io/frontend-config: api-ingress-frontend-config
networking.gke.io/pre-shared-cert: ingress-certificate-my

EDIT: kubectl describe crd frontendconfigs.networking.gke.io returns the following:

Name:         frontendconfigs.networking.gke.io
Namespace:    
Labels:       <none>
Annotations:  <none>
API Version:  apiextensions.k8s.io/v1
Kind:         CustomResourceDefinition
Metadata:
  Creation Timestamp:  2021-10-29T12:39:10Z
  Generation:          1
  Managed Fields:
    API Version:  apiextensions.k8s.io/v1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        f:conversion:
          .:
          f:strategy:
        f:group:
        f:names:
          f:kind:
          f:listKind:
          f:plural:
          f:singular:
        f:scope:
        f:versions:
      f:status:
        f:acceptedNames:
          f:kind:
          f:plural:
        f:conditions:
        f:storedVersions:
    Manager:         glbc
    Operation:       Update
    Time:            2021-10-29T12:48:18Z
  Resource Version:  2865
  UID:               ae694fde-68cf-4cea-ad7f-6c2f1490f8ae
Spec:
  Conversion:
    Strategy:  None
  Group:       networking.gke.io
  Names:
    Kind:       FrontendConfig
    List Kind:  FrontendConfigList
    Plural:     frontendconfigs
    Singular:   frontendconfig
  Scope:        Namespaced
  Versions:
    Name:  v1beta1
    Schema:
      openAPIV3Schema:
        Properties:
          API Version:
            Description:  APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            Type:         string
          Kind:
            Description:  Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            Type:         string
          Metadata:
            Type:  object
          Spec:
            Description:  FrontendConfigSpec is the spec for a FrontendConfig resource
            Properties:
              Redirect To Https:
                Description:  HttpsRedirectConfig representing the configuration of Https redirects
                Properties:
                  Enabled:
                    Type:  boolean
                  Response Code Name:
                    Description:  String representing the HTTP response code Options are MOVED_PERMANENTLY_DEFAULT, FOUND, TEMPORARY_REDIRECT, or PERMANENT_REDIRECT
                    Type:         string
                Required:
                  enabled
                Type:  object
              Ssl Policy:
                Type:  string
            Type:      object
          Status:
            Type:  object
        Type:      object
    Served:        true
    Storage:       true
Status:
  Accepted Names:
    Kind:       FrontendConfig
    List Kind:  FrontendConfigList
    Plural:     frontendconfigs
    Singular:   frontendconfig
  Conditions:
    Last Transition Time:  2021-10-29T12:39:10Z
    Message:               no conflicts found
    Reason:                NoConflicts
    Status:                True
    Type:                  NamesAccepted
    Last Transition Time:  2021-10-29T12:39:10Z
    Message:               the initial names have been accepted
    Reason:                InitialNamesAccepted
    Status:                True
    Type:                  Established
  Stored Versions:
    v1beta1
Events:  <none>

[boredabdel]

@Gageperrin can you please log an issue against our repo ? https://github.com/GoogleCloudPlatform/gke-networking-recipes

Sorry for asking to duplicate the work but i rather keep our examples bugs in our own repo, just tag me and i will have a look right away

Thanks

[boredabdel]

Please also share all your YAML files (MCI, MCS, Deployment, FrontendConfig, and BackendConfig if you have one). Screenshots could help too.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[heyitsjoealongi]

Following these two steps, worked for me, there are articles all over that have the leadup steps, the documentation here should be the latest.

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

1. Associating the Ingress & Frontend Configuration

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "FRONTENDCONFIG_NAME"

2. Frontend Configuration

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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

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.

[fuog]

For all those interested in the second half of the implementation, please help upvoting the Issuetracker:
Internal HTTP-to-HTTPS redirection support
https://issuetracker.google.com/issues/265398146
@red8888 @boredabdel

[goobysnack]

Apologies if this is obvious, but where can we find a list of acceptable annotations and spec for these resource kinds (ingress, multiclusteringress, for example)? The two are not directly translatable, so conversion is not straightforward.

[ivankorn]

/reopen

[k8s-ci-robot]

@ivankorn: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

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-sigs/prow repository.