-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HCM: add support for IP detection extensions #14855
HCM: add support for IP detection extensions #14855
Conversation
This is a follow-up to: envoyproxy#14432 (comment) After that PR, it's no longer possible (unless you do a dynamic_cast) to set the remote address from a filter. This is something that we need to do because we have specialized logic for this (XFF doesn't work for us). So this adds an extension point which will allow us to push that logic down to ConnectionManagerUtility::mutateRequestHeaders() where it belongs. Signed-off-by: Raul Gutierrez Segales <[email protected]>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is going to be awesome - thanks for adding it!
Two actual comments (ignoring the usual "docs, config examples, blah blah" which I'm sure you'll do as this goes out of WIP)
also cc @snowp in case he's interested and @antoniovicente @penguingao @AndresGuedez for visibility - we may want to move our own client IP calculations into an in-house extension.
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
I think you could get away with original_ip_detection as I don't know anyone who does this for upstream connections and it makes it a tiny bit less verbose :-P |
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Not sure where to put a full example of how to configure an extension. Signed-off-by: Raul Gutierrez Segales <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Providing a review pass for API shepherds. @phlax are there any documentation requirements from your side?
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
im thinking that it would be useful to add a sandbox that demonstrated features/functonality of this filter also, it doesnt seem like there any ref docs, so im not 100% about how it works without tracking through source and figuring out im happy to add a sandbox, but it would be good if there was some explanation that i can work from |
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Yup -- I'll do another pass now and add proper examples/docs. |
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but a few API comments.
/wait
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto
Outdated
Show resolved
Hide resolved
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
The gcc failure is our old friend:
cc: @yanavlasov @phlax |
@htuch API is ready for another pass, I think I addressed most of your concerns directly (or indirectly). Thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM modulo nits.
api/envoy/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
Signed-off-by: Raul Gutierrez Segales <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm api
I don't think the x64 coverage failure is related:
Looking into it... |
That's not real the error, trying to find the test log to see what happened. |
/retest |
Retrying Azure Pipelines: |
This is a follow-up to: After that PR, it's no longer possible (unless you do a dynamic_cast) to set the remote address from a filter. This is something that we need to do because we have specialized logic for this (XFF doesn't work for us). So this adds an extension point which will allow us to push that logic down to ConnectionManagerUtility::mutateRequestHeaders() where it belongs.
This is a follow-up to: After that PR, it's no longer possible (unless you do a dynamic_cast) to set the remote address from a filter. This is something that we need to do because we have specialized logic for this (XFF doesn't work for us). So this adds an extension point which will allow us to push that logic down to ConnectionManagerUtility::mutateRequestHeaders() where it belongs Signed-off-by: Raúl Gutiérrez Segalés <[email protected]>
This is a follow-up to: envoyproxy#14432 (comment) After that PR, it's no longer possible (unless you do a dynamic_cast) to set the remote address from a filter. This is something that we need to do because we have specialized logic for this (XFF doesn't work for us). So this adds an extension point which will allow us to push that logic down to ConnectionManagerUtility::mutateRequestHeaders() where it belongs. Signed-off-by: Raul Gutierrez Segales <[email protected]> Signed-off-by: Sixiang Gu <[email protected]>
return std::make_shared<Extensions::Http::OriginalIPDetection::Xff::XffIPDetection>(hops); | ||
} | ||
|
||
Http::OriginalIPDetectionSharedPtr getCustomHeaderExtension(const std::string& header_name) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rgs1 I think this file violates that extensions should be independent of each other, requiring both extensions to be enabled.
WDYT is the right way to get around this? Does this just null the point of this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is there to workaround the Envoy::Http
vs Envoy::Extensions::Http
namespaces pollution. How why are both extensions required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think from the bazel perspective the if you disable one of them here:
# Original IP detection |
it'll only stop the factory registration. So if you want to test just one of them, and you use this file, both of these extensions end up being linked into the binary I believe with the other one (or N other IP detection extension if this pattern is repeated in the future) would just end up as dead code.
Seems like it's probably better to link the minimal set of what you'd use in a given situation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
possibly related - i was trying to update the envoy checkout on envoy-mobile (envoyproxy/envoy-mobile#1481)
i had to link in the xff code - its failing, possibly for some other reason - but something tells me that this will also cause an issue
not totally sure - as xff at least is listed in all_extensions.bzl
which kinda overrides envoy_build_config.bzl
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm it's also here:
# The map may be overridden by extensions specified in envoy_build_config.
_required_extensions = {
"envoy.common.crypto.utility_lib": "//source/extensions/common/crypto:utility_lib",
+ "envoy.http.original_ip_detection.xff": "//source/extensions/http/original_ip_detection/xff:config",
"envoy.request_id.uuid": "//source/extensions/request_id/uuid:config",
"envoy.transport_sockets.tls": "//source/extensions/transport_sockets/tls:config",
}
…cab (#8346) * xds: sync envoy proto to commit 62ca8bd2b5960ed1c6ce2be97d3120cee719ecab * Suppress warnings for newly deprecated xDS proto fields Sync to the latest update to pick up envoyproxy/envoy#16942 for forward compatibility with upcoming xDS Rate Limiting features. Internal Envoy import CL for `62ca8bd2b5960ed1c6ce2be97d3120cee719ecab`: cl/381356375 Suppressed warnings for newly deprecated xDS proto fields: 1) `PerXdsConfig xds_config` to be replaced with `GenericXdsConfig generic_xds_configs`, but this work yet to be planned 2) `HttpConnectionManager`'s `uint32 setXffNumTrustedHops` to be replaced with `TypedExtensionConfig OriginalIpDetectionExtensions`: envoyproxy/envoy#14855
This is a follow-up to:
#14432 (comment)
After that PR, it's no longer possible (unless you do a dynamic_cast)
to set the remote address from a filter. This is something that we
need to do because we have specialized logic for this (XFF doesn't
work for us).
So this adds an extension point which will allow us to push that logic
down to ConnectionManagerUtility::mutateRequestHeaders() where it
belongs.
Signed-off-by: Raul Gutierrez Segales [email protected]