Support global level http -> https redirection
See original GitHub issueUse Case If TLS terminates externally (Such as AWS ELB), the http request need to be redirected to https.
Describe the solution you’d like The solution that I can think of is twofold. One, to be able to identify and match the protocol. (http/https), and second to be able to add permenant redirection for a URL. Both have their own use cases to be able to be used separately.
A config for permanent redirection may look like
prefix: /
port: 80
ssl: off
redirect: https://<hostname>
redirection_type: permanent
Describe alternatives you’ve considered Another alternative is to use something like cloudflare to do the redirection.
Additional context Currently we ended up using AWS cloud front for doing redirection. However, cloudfront is not able to handle websocket. Hence we may have to move to nginx-ingress to be able to do this.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:3
- Comments:15 (11 by maintainers)
Top Results From Across the Web
Support global level http -> https redirection · Issue #469
I terminate SSL with an AWS ELB. I'm currently using NGINX for the redirect and I'm looking at migrating to ambassador. AWS provides...
Read more >Set up an HTTP-to-HTTPS redirect for a global external HTTP ...
Redirecting traffic to your HTTPS load balancer · In the Google Cloud console, go to the Load balancing page. · Under HTTP(S) load...
Read more >How to Redirect Website from HTTP to HTTPS? - Geekflare
Go HTTPS; it doesn't cost anything, and yet you get search engine ranking and security. HTTPS should be everywhere, and lately, Google has...
Read more >HTTP Redirects with DNS, and Why HTTPS Redirects are So
Redirects are commonly used to tell website visitors and search engines which ... No, you cannot redirect HTTP to HTTPS at the DNS...
Read more >Use an Application Load Balancer to redirect HTTP to HTTPS
Create an HTTP listener rule that redirects HTTP requests to HTTPS. Open the Amazon EC2 console. Under Load Balancing in the sidebar, choose ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Heads up this is actually a trickier problem than it seems. Let me explain (lots of words and context coming in):
First, for those unfamiliar with AWS there are three types of load balancers:
“Classic” Load Balancer (abbreviated ELB or CLB, sometimes referred to as ELBv1 or Elastic Load Balancer)
Application Load Balancer (abbreivated ALB, sometimes referred to as ELBv2)
Network Load Balancer (abbreviated NLB).
In Kubernetes land when using the AWS integration and a
v1.Service -> type: LoadBalancer
the only types of infrastructure load balancers you can create are:Further in the case of a Classic Load Balancer it can be configured to run in either L4 or L7 mode but not both from Kubernetes, this is an important piece of information. Ambassador is designed to be a generic API gateway. That means most likely folks want to deploy Ambassador in a way that developers can use whatever protocol they desire on the backend (HTTP, websockets, GRPC, etc.).
Further, operators usually love to use SSL/TLS offload when on AWS. In AWS you can setup load balancers to use the Amazon Certificate Manager (“ACM”) which handles all the security concerns around managing SSL/TLS certificates and makes setting up SSL/TLS for a load balancer as trivial as a one line configuration reference to a named certificate in the ACM system.
So to restate some assumptions / facts about when on AWS:
A problem emerges, The
X-Forwarded-Proto
cannot be added to incoming HTTP requests by the ELB when running TCP+SSL mode because it does not know what protocol it is speaking (it is afterall just a dumb L4 load balancer).So what to do? There are a couple solutions and they pose UX challenges for us:
If a user runs the load balancer in L7 mode (HTTPS) then we can do something with
X-Forwarded-Proto
(we need to run a test). This obviously comes with the drawback that they cannot use websockets or GRPC through the load balancer.If a user runs the load balancer in L4 mode (TCP+SSL) then we have a signifigantly different problem. There is no protocol information that the ELB can provide to Envoy va
X-Forwarded-Proto
. The only option in this case is::443
->:8443
(the envoy port doesn’t matter):80
->:8080
(the envoy port doesn’t matter):8080
we need to issue theHTTP 301
. We are making an implicit assumption that this is HTTP (insecure). This is the only way to distinguish traffic absentX-Forwarded-Proto
that I can think of.How we want to expose this via Ambassador is the tricky bit.
@plombardi89 that’s interesting thank you. I can appreciate the complexity of having a solution that should work with all possible deployment architectures.
Perhaps this tells us that it would be better not to try to make a solution that works in all cases. You could provide a way to redirect if a given header (e.g.
X-Forwarded-Proto
) is equals to a given value (e.g.http
), which would only work when such header exists (e.g. with L7 ELB).If there are no such header then as you said there is nothing more you can do. In this case you can provide the workaround you suggested above.
In the documentation, you currently have a section about terminating TLS at the Ambassador level. Perhaps it would be good to have another section about terminating TLS at the Cloud Provider level (e.g. ELB). You could use this section to explain the new redirect with header option and the workaround if no such header exists.