mesh: support configuring XFF trusted cidrs #3344
Conversation
|
😊 Welcome @rudrakhp! This is either your first contribution to the Istio api repo, or it's been You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines Thanks for contributing! Courtesy of your friendly welcome wagon. |
istio-testing
added
the
size/S
rudrakhp
force-pushed
the
xff_trusted_cidrs
branch
from
e616c7d to
76fbb00
Compare
rudrakhp
force-pushed
the
xff_trusted_cidrs
branch
2 times, most recently
from
6e02798 to
902e15f
Compare
rudrakhp
force-pushed
the
xff_trusted_cidrs
branch
from
902e15f to
104a221
Compare
Signed-off-by: Rudrakh Panigrahi <[email protected]>
rudrakhp
force-pushed
the
xff_trusted_cidrs
branch
from
104a221 to
f1f3a7b
Compare
|
@istio/technical-oversight-committee bumping this up. Thanks! |
| // If all addresses in X-Forwarded-For (XFF) header are within the trusted list, the first (leftmost) entry is used. | ||
| // See [Envoy XFF](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-forwarded-for) | ||
| // header handling for more details. Only one of `numTrustedProxies` and `trustedCidrs` may be set. | ||
| repeated string trusted_cidrs = 4; |
There was a problem hiding this comment.
The envoy docs say we cannot use it with UseRemoteAddress. UseRemoteAddress is currently always set to 'true' for gateways.
What will be the behavior if a user sets this? Will we set useRemoteAddress=false? What side effects does this have beyond deciding how to parse the XFF header?
There was a problem hiding this comment.
@howardjohn Yes we will have to always set UseRemoteAddress to false if we decide to use the XFF original IP detection extension (which is recommended over the alternative we use today, might soon be on deprecation path).
What side effects does this have beyond deciding how to parse the XFF header?
From the docs it does look like the only thing that changes is how the original IP is determined, HCM does it natively today, we will be moving to original IP detection extension.
Meanwhile waiting on a probable fix for difference in behaviour of HCM and the XFF origin detection extension: envoyproxy/envoy#37780
istio-testing
added
the
needs-rebase
|
PR needs rebase. 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. |
Ref istio/istio#53185
Related feature in envoy here.