Skip to content
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

Merged
merged 175 commits into from
May 16, 2021

Conversation

rgs1
Copy link
Member

@rgs1 rgs1 commented Jan 28, 2021

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]

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]>
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/envoy/.
API shepherd assignee is @mattklein123
CC @envoyproxy/api-watchers: FYI only for changes made to api/envoy/.

🐱

Caused by: #14855 was opened by rgs1.

see: more, trace.

@alyssawilk alyssawilk self-assigned this Jan 28, 2021
@snowp snowp self-assigned this Jan 28, 2021
Copy link
Contributor

@alyssawilk alyssawilk left a 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.

@alyssawilk
Copy link
Contributor

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

Raul Gutierrez Segales added 4 commits January 29, 2021 15:59
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]>
Copy link
Member

@htuch htuch left a 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?

@phlax
Copy link
Member

phlax commented Jan 31, 2021

@phlax are there any documentation requirements from your side?

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

@rgs1
Copy link
Member Author

rgs1 commented Feb 2, 2021

@phlax are there any documentation requirements from your side?

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

Yup -- I'll do another pass now and add proper examples/docs.

Raul Gutierrez Segales added 2 commits February 1, 2021 20:28
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
@rgs1 rgs1 changed the title [WIP] HCM: add support for IP detection extensions HCM: add support for IP detection extensions Feb 2, 2021
Raul Gutierrez Segales added 3 commits February 2, 2021 10:25
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Copy link
Member

@htuch htuch left a 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

Raul Gutierrez Segales added 3 commits May 13, 2021 14:43
Raul Gutierrez Segales added 3 commits May 13, 2021 16:59
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Signed-off-by: Raul Gutierrez Segales <[email protected]>
Fix
Signed-off-by: Raul Gutierrez Segales <[email protected]>
@rgs1
Copy link
Member Author

rgs1 commented May 14, 2021

The gcc failure is our old friend:

fatal error: cannot execute ‘/usr/lib/gcc/x86_64-linux-gnu/9/cc1plus’: execv: Argument list too long

cc: @yanavlasov @phlax

@rgs1
Copy link
Member Author

rgs1 commented May 14, 2021

@htuch API is ready for another pass, I think I addressed most of your concerns directly (or indirectly). Thanks!

Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM modulo nits.

Raul Gutierrez Segales added 2 commits May 14, 2021 10:07
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm api

@rgs1
Copy link
Member Author

rgs1 commented May 14, 2021

I don't think the x64 coverage failure is related:

FAIL: //test/integration:protocol_integration_test (shard 3 of 5) (see /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/k8-fastbuild/testlogs/test/integration/protocol_integration_test/shard_3_of_5/test.log)
stdout (/build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/_tmp/actions/stdout-18662) exceeds maximum size of --experimental_ui_max_stdouterr_bytes=1048576 bytes; skipping

Looking into it...

@rgs1
Copy link
Member Author

rgs1 commented May 14, 2021

I don't think the x64 coverage failure is related:

FAIL: //test/integration:protocol_integration_test (shard 3 of 5) (see /build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/k8-fastbuild/testlogs/test/integration/protocol_integration_test/shard_3_of_5/test.log)
stdout (/build/tmp/_bazel_envoybuild/b570b5ccd0454dc9af9f65ab1833764d/execroot/envoy/bazel-out/_tmp/actions/stdout-18662) exceeds maximum size of --experimental_ui_max_stdouterr_bytes=1048576 bytes; skipping

Looking into it...

That's not real the error, trying to find the test log to see what happened.

@rgs1
Copy link
Member Author

rgs1 commented May 14, 2021

/retest

@repokitteh-read-only
Copy link

Retrying Azure Pipelines:
Check envoy-presubmit isn't fully completed, but will still attempt retrying.
Retried failed jobs in: envoy-presubmit

🐱

Caused by: a #14855 (comment) was created by @rgs1.

see: more, trace.

@htuch htuch merged commit beac1ec into envoyproxy:main May 16, 2021
soulxu pushed a commit to soulxu/envoy that referenced this pull request May 18, 2021
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.
soulxu pushed a commit to soulxu/envoy that referenced this pull request May 18, 2021
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]>
ntgsx92 pushed a commit to ntgsx92/envoy that referenced this pull request May 18, 2021
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) {
Copy link
Contributor

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?

Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Member Author

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",
 }

sergiitk added a commit to grpc/grpc-java that referenced this pull request Jul 27, 2021
…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
@rgs1 rgs1 mentioned this pull request Jul 30, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.