feat:support configuring xff trusted cidrs

[rudrakhp]

What type of PR is this?

feat:support configuring xff trusted cidrs

What this PR does / why we need it:

Implement API introduced in #4500

Which issue(s) this PR fixes:

Refer #4489

Release Notes: No

[codecov]

Codecov Report

Attention: Patch coverage is 80.55556% with 7 lines in your changes missing coverage. Please review.

Project coverage is 65.62%. Comparing base (d1a8c47) to head (66d9135).

Files with missing lines	Patch %	Lines
internal/ir/xds.go	0.00%	6 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4702      +/-   ##
==========================================
+ Coverage   65.59%   65.62%   +0.02%     
==========================================
  Files         211      211              
  Lines       31999    32034      +35     
==========================================
+ Hits        20990    21022      +32     
- Misses       9765     9768       +3     
  Partials     1244     1244              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[arkodg]

hey @rudrakhp can we add an e2e for this in this PR, or can you confirm this works by testing manually (and e2e can be added in a follow up)

[rudrakhp]

@arkodg I tried to use original IP detection extension's xff_num_trusted_hops instead of the same param in the parent HCM filter (which is on deprecation path according to envoy community). But looks like it's breaking RBAC somehow (this e2e was failing). Started a thread envoyproxy/envoy#37140 to understand this further.
Meanwhile only using xff_trusted_cidrs in the new extension to ensure no change in NumTrustedHops behaviour. Just an FYI in case we might decide to use the extension for NumTrustedHops as well in the future which will require us to fix this.
I will add E2E for trusted CIDRs in this PR to ensure functionality.

[zhaohuabing]

@arkodg I tried to use original IP detection extension's xff_num_trusted_hops instead of the same param in the parent HCM filter (which is on deprecation path according to envoy community). But looks like it's breaking RBAC somehow (this e2e was failing). Started a thread envoyproxy/envoy#37140 to understand this further. Meanwhile only using xff_trusted_cidrs in the new extension to ensure no change in NumTrustedHops behaviour. Just an FYI in case we might decide to use the extension for NumTrustedHops as well in the future which will require us to fix this. I will add E2E for trusted CIDRs in this PR to ensure functionality.

@rudrakhp This is probably related to envoyproxy/envoy#34241

[rudrakhp]

According to HCM docs:

Extensions cannot be used in conjunction with use_remote_address nor xff_num_trusted_hops.

But due to known issues mentioned earlier, not able to move legacy num trusted hops to the new extension. Moving PR to draft till the envoy issue is resolved.

[zhaohuabing]

@rudrakhp

But due to known issues mentioned earlier, not able to move legacy num trusted hops to the new extension. Moving PR to draft till the envoy issue is resolved.

To move this PR ahead, We probably could modify the existing RBAC e2e.

numTrustedHops: 2

gateway/test/e2e/testdata/authorization-client-ip.yaml

Line 94 in 2a10d47

numTrustedHops: 1

But I'm not sure which behavior is correct, the HCM xff_num_trusted_hops or the xff extension.

[zhaohuabing]

Raised a PR envoyproxy/envoy#37780 to seek help from the Enovy maintainers.

[rudrakhp]

To move this PR ahead, We probably could modify the existing RBAC e2e.

Not sure if that's the right thing to do, isn't it essentially changing behaviour for EGW users, probably breaking?