l7 policy: add possibility to configure Envoy proxy xff-num-trusted-hops #32200
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mhofstetter
added
area/proxy
|
/test |
mhofstetter
force-pushed
the
pr/mhofstetter/proxy-xff-hops
branch
2 times, most recently
from
2e95a6d
to
a192f38
Compare
mhofstetter
changed the title
mhofstetter
force-pushed
the
pr/mhofstetter/proxy-xff-hops
branch
from
a192f38
to
c78dd75
Compare
mhofstetter
added
needs-backport/1.14
|
/test |
mhofstetter
added
the
backport/author
qmonnet
requested changes
Apr 29, 2024
Currently, when L7 policies (egress or ingress) are enforced for traffic between Pods, Envoy might change x-forwarded-for related headers because the corresponding Envoy listeners don't trust the downstream headers because `XffNumTrustedHops` is set to `0`. e.g. `x-forwarded-proto` header: > Downstream x-forwarded-proto headers will only be trusted if xff_num_trusted_hops is non-zero. If xff_num_trusted_hops is zero, downstream x-forwarded-proto headers and :scheme headers will be set to http or https based on if the downstream connection is TLS or not. https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-proto This might be problematic if L7 policies are used for egress traffic for Pods from a non-Cilium ingress controller (e.g. nginx). If the Ingress Controller is terminating TLS traffic and forwards the protocol via `x-forwarded-proto=https`, Cilium Envoy Proxy changes this header to `x-forwarded-proto=http` (if no tls termination itself is used in the policy configuration). This breaks applications that depend on the forwarded protocol. Therefore, this commit introduces two new config flags `proxy-xff-num-trusted-hops-ingress` and `proxy-xff-num-trusted-hops-egresss` that configures the property `XffNumTrustedHops` on the respective L7 policy Envoy listeners. For backwards compabitility and security reasons, the values still default to `0`. Note: It's also possible to configure these values via Helm (`envoy.xffNumTrustedHopsL7PolicyIngress` & `envoy.xffNumTrustedHopsL7PolicyEgress`). Signed-off-by: Marco Hofstetter <marco.hofstetter@isovalent.com>
mhofstetter
force-pushed
the
pr/mhofstetter/proxy-xff-hops
branch
from
c78dd75
to
d0d5c50
Compare
Thanks @qmonnet 🚀 🙏 - I incorporated your feedback! PTAL. |
|
/test |
squeed
approved these changes
Apr 30, 2024
maintainer-s-little-helper
bot
added
the
ready-to-merge
mhofstetter
added
backport-pending/1.15
maintainer-s-little-helper
bot
moved this from Needs backport from main
to Backport pending to v1.15
in 1.15.5
mhofstetter
added
backport-pending/1.14
maintainer-s-little-helper
bot
moved this from Needs backport from main
to Backport pending to v1.14
in 1.14.11
github-actions
bot
added
backport-done/1.14
github-actions
bot
added
backport-done/1.15
maintainer-s-little-helper
bot
moved this from Backport pending to v1.15
to Backport done to v1.15
in 1.15.5
This was referenced May 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when L7 policies (egress or ingress) are enforced for traffic
between Pods, Envoy might change x-forwarded-for related headers because the corresponding
Envoy listeners don't trust the downstream headers because
XffNumTrustedHopsis set to
0.e.g.
x-forwarded-protoheader:https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-proto
This might be problematic if L7 policies are used for egress traffic for Pods from
a non-Cilium ingress controller (e.g. nginx). If the Ingress Controller is terminating TLS
traffic and forwards the protocol via
x-forwarded-proto=https, Cilium Envoy Proxy changesthis header to
x-forwarded-proto=http(if no tls termination itself is used in the policy configuration).This breaks applications that depend on the forwarded protocol.
Therefore, this commit introduces two new config flags
proxy-xff-num-trusted-hops-ingressandproxy-xff-num-trusted-hops-egresssthat configures the propertyXffNumTrustedHopson the respectiveL7 policy Envoy listeners.
For backwards compabitility and security reasons, the values still default to
0.Note: It's also possible to configure these values via Helm (
envoy.xffNumTrustedHopsL7PolicyIngress&envoy.xffNumTrustedHopsL7PolicyEgress).