fix: proxies going from HTTP => HTTPS: matching upstream http(s) scheme#7842
Conversation
This makes it possible to use gateways that are internally exposed to Kubernetes as an HTTP service that proxies to a strictly HTTPS service. Some HTTPS services will declare a protocol error when an HTTPS request is forwarded towards them but the HTTP2 `:scheme` header is still set to `http`. Signed-off-by: Andreas Wachs <awa@corti.ai>
Signed-off-by: Andreas Wachs <awa@corti.ai>
|
xref: envoyproxy/envoy#33020 |
Example usage now:
```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: BackendTrafficPolicy
metadata:
name: match-upstream-scheme
namespace: envoy-gateway
spec:
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: my-gateway
upstreamScheme: MatchUpstream # or PreserveDownstream (default)
```
Signed-off-by: Andreas Wachs <awa@corti.ai>
| // +optional | ||
| UseClientProtocol *bool `json:"useClientProtocol,omitempty"` | ||
|
|
||
| // UpstreamScheme configures how the :scheme pseudo-header is set for requests forwarded to backends. |
There was a problem hiding this comment.
can we use Client and Backend instead of Downstream and Upstream to match existing API
There was a problem hiding this comment.
I have added a commit with renames - let me know if you like it or if there are more adjustments needed
There was a problem hiding this comment.
still using Downstream and Upstream in the Enums
There was a problem hiding this comment.
Ah sorry I have missed this
There was a problem hiding this comment.
@arkodg would it make sense to rename the field new field clientScheme that this PR introduces on the BackendTrafficPolicy spec to scheme instead if I rename the enum values to Preserve and MatchBackend?
There was a problem hiding this comment.
I've renamed the field (and also moved it to the Client Traffic Policy CR)
Signed-off-by: Andreas Wachs <awa@corti.ai>
✅ Deploy Preview for cerulean-figolla-1f9435 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Signed-off-by: Andreas Wachs <awa@corti.ai>
Signed-off-by: Isaac Wilson <10012479+jukie@users.noreply.github.com>
Signed-off-by: Isaac Wilson <10012479+jukie@users.noreply.github.com>
|
Fixed the merge conflict but needs a |
Signed-off-by: Andreas Wachs <awa@corti.ai>
Thank you - done! |
|
Still failing @andreaswachs |
Signed-off-by: Andreas Wachs <awa@corti.ai>
Signed-off-by: Andreas Wachs <andreas@wachs.email>
731a852 to
68c0919
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #7842 +/- ##
==========================================
+ Coverage 73.77% 73.85% +0.07%
==========================================
Files 237 237
Lines 35754 35763 +9
==========================================
+ Hits 26379 26412 +33
+ Misses 7516 7498 -18
+ Partials 1859 1853 -6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
I'm sorry, I failed to run all the CI checks that I could locally. I see they are working now and thank you for the approval! Are the Ci checks on the PR something that I can trigger myself or need it be some of you guys? |
|
For first time contributors you'll need someone to approve the workflow run upon each commit but in the future they'll be automatic. |
Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com>
|
Thanks a lot for this @andreaswachs! |
…me (envoyproxy#7842) * fix(translator): matching upstream http(s) scheme This makes it possible to use gateways that are internally exposed to Kubernetes as an HTTP service that proxies to a strictly HTTPS service. Some HTTPS services will declare a protocol error when an HTTPS request is forwarded towards them but the HTTP2 `:scheme` header is still set to `http`. Signed-off-by: Andreas Wachs <awa@corti.ai> * rename `UpstreamScheme` to `ClientScheme` in the public facing API Signed-off-by: Andreas Wachs <awa@corti.ai> Signed-off-by: Sadmi Bouhafs <sadmibouhafs@gmail.com>
This makes it possible to use gateways that are internally exposed to Kubernetes as an HTTP service that proxies to a strictly HTTPS service. Some HTTPS services will declare a protocol error when an HTTPS request is forwarded towards them but the HTTP2
:schemeheader is still set tohttp.What type of PR is this?
This fixes issues with proxying from an internally exposed HTTP proxy, that proxies to strict HTTPS services
What this PR does / why we need it:
I have found issues with a Envoy Gateway deployment that is internal to a Kubernetes cluster, exposed with an HTTP listener. It is talking to an HTTP/2 service that strictly speaks HTTPS. The
:schememeta header were being passed from the downstream source ashttpeven though the backend were configured as HTTPS.This remediation attempts to base the scheme of the proxied requests to match what the upstream is serving.
The same issue in spirit has been discussed before, specifically for the Envoy Proxy: envoyproxy/envoy#16255
I have tested this change in a local kind cluster hand have found it to fix my issue.
Note to reviewers: I am not well versed in this Envoy Gateway code base and I welcome any and all critique and comments. I don't have the experience to foresee the consequences of this change for users, if there are any.
Release Notes: Yes
Fixes #7979