Feature request: support external TLS with HTTP 301 upgrades

[davecheney]

Currently Contour configures Envoy to handle TLS directly on port 8443. If this is enabled then a second option to issue 301 redirects from port 8080 to port 8443 is available, via an annotation on Ingress, and automatically via IngressRoute.

Currently it is not possible to configure contour to both issue 301 upgrades to HTTP requests and have TLS managed externally (say an ELB managed by a cloud provider). We should look into making this possible.

[so0k]

We recently switched from zalando/kube-ingress-aws-controller + zalando/skipper to zalando/kube-ingress-aws-controller + heptio/contour.

Currently setting ingress.kubernetes.io/force-ssl-redirect on our ingress results in a redirect loop

Would there be a simple way to check for X-Forwarded-Proto header and not redirect if it's there?

Ideally, the logic of creating external LB and setting the ingress status remains de-coupled from contour to have maximum flexibility. I love how it works right now.

Here are some details why someone might want to use kube-ingress-aws-controller

• Uses minimum AWS API calls to create ALB+TargetGroup (CloudFormation Stack)
• Supports custom filters for (Spot) Instance / ASG tags dynamically added to TargetGroup (allowing us to dedicate Edge Nodes for ingress)
• Fully automated ALB Listener Cert configuration with AWS Certificate Management (external TLS)

I do not think I can achieve the same with Kubernetes Service objects of type LoadBalancer (they would distribute traffic across all nodes instead of just edge nodes?

Looking forward to your thoughts and comments

[so0k]

Switching to NLBs due to bugs in ALB, this is of lower priority for me now

[so0k]

other ppl reported this bug here - https://github.com/envoyproxy/envoy/issues/4496#issuecomment-461293693