This PR adds support for configuring round-robin nameserver
selection in the c-ares DNS resolver.
When enabled, this will rotate through the configured nameservers for
each resolution request, helping to distribute query load across
multiple nameservers.
The feature allows better load distribution across multiple nameservers
without requiring any changes to DNS server configuration.
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ b5c15a323dc20d02a50ee31227bb353cd8069df2
## Background
This PR adds a new option called `sourced_metadata` to RBAC permissions
and principals which allows specifying an optional source for the
metadata to be matched. Currently it only supports Dynamic Metadata and
Route Metadata. More options could be added later.
**Fixes:** #34913
---
**Commit Message:** rbac: add support for matching on route metadata
**Additional Description:** This PR adds a new option called
`sourced_metadata` to RBAC permissions and principals which allows
specifying an optional source for the metadata to be matched.
**Risk Level:** Low
**Testing:** Added Unit & Integration Tests
**Docs Changes:** Added
**Release Notes:** Added
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8aabe0f9ae2834985f92b6a5e378a8c93bce0c7c
These options are related, but do not have to be used together.
The existing `auto_sni` and `auto_san_validation` make Envoy set
upstream TLS SNI and validate SANs based on the downstream requests's
`:authority` (or override header).
The new `auto_host_sni` option causes Envoy to set the upstream TLS SNI
to the hostname in the cluster for the host being connected to. For
example, in a DNS cluster with server1.example.com and server2.example
as the cluster members, connections would have SNI of
server1.example.com and server2.example.com, respectively.
The new `auto_sni_san_validation` option causes Envoy to validate that
the peer's server certificate has a DNS SAN that matches whatever SNI
value was sent (regardless of how it's configured). This is appropriate
to set in many/most configurations for normally-behaving upstream
servers without special certificate validation requirements.
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8ef1ecc4fae1699b8fcea839a510a8a760ddecd8
This PR is for issue: https://github.com/envoyproxy/envoy/issues/32090.
One of the use case is, like compression by the external processing.
This is to let the ext_proc server be able to buffer M request body
chunks from Envoy first, processing them, then send N chunks back to
Envoy in the STREAMED mode. It also let the server buffer the entire
message, i.e, header, body, trailer, before sending back any response.
The ext_proc MXN streaming works this way:
1) Enable the MXN streaming by configuring the body mode to be
FULL_DUPLEX_STREAMED in the ext_proc filter config.
2) Config the trailer mode to be SEND in the ext_proc filter config.
With above config, Envoy will send body to the ext_proc server as they
arrival. The server can buffer the entire or partial of the body (M
chunks) then streaming the mutated body(may need to split into N
chunks), back to Envoy.
---------
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 72a20671ae70db520226388bfd351e817393d66e
An internal tool we have notified us that some API fields and
enum-values that we use do not have comments.
I've added some comments, and updated some of the ext-proc comments to
make it a bit clearer.
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 522c94a5e7804057433d8d5cc79aa236a564c279
## Background
We recently saw a small number of DNS queries getting timed out. There
is currently no option for us to [initialize
c-ares](https://c-ares.org/ares_init_options.html) by passing in a
custom
[timeout](https://c-ares.org/ares_init_options.html#:~:text=c%2Dares%201.5.2.-,ARES_OPT_TIMEOUTMS,-int%20timeout%3B)
and
[tries](https://c-ares.org/ares_init_options.html#:~:text=c%2Dares%201.5.2.-,ARES_OPT_TRIES,-int%20tries%3B)
config options.
## Changes
In this PR, we are adding two new options in c-ares resolver for
configuring custom timeouts and tries while resolving DNS queries.
Custom timeouts could be configured by specifying
`query_timeout_seconds` option and custom tries could be configured by
specifying `query_tries` config option.
**Commit Message:** dns resolver: add options to initialize c-ares with
custom timeout and tries
**Additional Description:** add two new options called
`query_timeout_seconds` and `query_tries` for initializing c-ares with
custom timeout and tries.
**Risk Level:** Low
**Testing:** Added Unit/Integration Tests
**Docs Changes:** Added
**Release Notes:** Added
**Platform Specific Features:** N/A
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0a2e904c7f1b8232e5e9700f2d995a76f4c84014
# Description
This change adds support for specifying an optional header to ip-tagging
filter instead of the default header that it uses (`x-envoy-ip-tags`).
example
```
http_filters
- name: ip.tagging
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.ip_tagging.v3.IPTagging
request_type: BOTH
ip_tag_header: "x-slack-foo-bar"
ip_tags: []
```
# Why
Currently, the ip-tagging filter always writes its output into the
`x-envoy-ip-tags` header. When this filter is used for more than one
purpose in the same filter chain which we do at Slack in our production
environment, we do need to take care of cleaning up the header in
between which has been proven a bit tricky sometimes. Leaking the values
in between the filter chain is bad so we try to avoid that.
We would like this to be configurable. This way we can use the optional
header instead of trying the use the same header however many times the
same filter is used on the same filter chain in a listener.
# Risk Level
this is a new feature, doesn't affect the existing functionality so
guessing low but open to changing if I'm wrong.
# Testing
added test
Docs Changes: Added, alongside release notes
Co-authored-by: Ariane van der Steldt
[avandersteldt@slack-corp.com](mailto:avandersteldt@slack-corp.com)
Signed-off-by: Radha Kumari
[rkumari@slack-corp.com](mailto:rkumari@slack-corp.com)
---------
Signed-off-by: Radha Kumari <rkumari@slack-corp.com>
Signed-off-by: Radha <kumari.radha3@gmail.com>
Signed-off-by: Radha <rkumari@slack-corp.com>
Signed-off-by: Ariane van der Steldt <avandersteldt@slack-corp.com>
Co-authored-by: Adi (Suissa) Peleg <adip@google.com>
Co-authored-by: Ariane van der Steldt <avandersteldt@slack-corp.com>
Mirrored from https://github.com/envoyproxy/envoy @ 414ad34fb35ea90e50c04d6ed85f884dd3921de7
Commit Message: kafka: close connection when rejectable request appears
Additional Description: provides
https://github.com/envoyproxy/envoy/issues/36978 by making the broker
filter check the requests' API key against allow/denylists in the config
- if we find a request to reject, we just close the connection. There is
also a bonus: this sets up a framework for "_close connection if we
don't like the request_" that we can expand upon later.
Risk Level: Low
Testing: automated (no filtering) + manual (filtering)
Docs Changes: Kafka broker .rst
Release Notes: n/a
Platform Specific Features: n/a
---------
Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c30d173544a6ac6646201f8766eb851c7c9e0bc6
<!--
!!!ATTENTION!!!
If you are fixing *any* crash or *any* potential security issue, *do
not*
open a pull request in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged
appropriately.
Thank you in advance for helping to keep Envoy secure.
!!!ATTENTION!!!
For an explanation of how to fill out the fields, please see the
relevant section
in
[PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
-->
This PR adds the API for HTTP APIKey Auth Filter that is proposed at
https://github.com/envoyproxy/envoy/issues/34877 and
https://github.com/envoyproxy/gateway/issues/2630.
Commit Message: api: HTTP APIKey Auth Filter
Risk Level: Low (only API)
Testing: WIP (will be done after we agree on the API)
Docs Changes: WIP
Release Notes: WIP
Platform Specific Features: No
Part of: #34877
---------
Signed-off-by: Kensei Nakada <handbomusic@gmail.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Co-authored-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Mirrored from https://github.com/envoyproxy/envoy @ 72b75074a0ee089ad81f68ae011e31f14c2936fe
add OLM scaling for max_connection_duration
This allows for configuring scaling the max connection duration in
response to overload.
Risk Level: low
Testing: integration & unit tests
Docs Changes: none
Release Notes: in changelog
---------
Signed-off-by: antoniovleonti <leonti@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ae4391145fb38487a3206e7b77c402d928857e7b
<!--
!!!ATTENTION!!!
If you are fixing *any* crash or *any* potential security issue, *do
not*
open a pull request in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged
appropriately.
Thank you in advance for helping to keep Envoy secure.
!!!ATTENTION!!!
For an explanation of how to fill out the fields, please see the
relevant section
in
[PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
-->
Commit Message: enable `use_refresh_token` by default in oauth2 filter.
Additional Description: Almost all oauth provider give you an option to
enable or disable sending refresh_token in response. If someone is
sending refresh_token, the intent is generally to use it. If not, the
same is not used and the behavior stays the same. This feature is now
pretty stable and can be enabled by default.
Risk Level: Low
Testing: UTs
Docs Changes: Present in the PR.
Release Notes: Need to mention about enabling `use_refresh_token` by
default.
Fixes#36045
---------
Signed-off-by: Anurag Aggarwal <kanurag94@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ ce3e47b93d507daa5bbc68bf6eb7e1f66d8800ec
Commit Message: wasm: restart wasm vm if it's failed
Additional Description:
A experimental PR that support automatic reloading when the wasm VM is
failed (panic(), abort(), etc).
Risk Level: low. The wasm is not production ready anyway.
Testing: unit. waiting.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.
---------
Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping/wbpcode <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Mirrored from https://github.com/envoyproxy/envoy @ 64b4d2e42bf400becbd4f9a5cde7fe6ab2e30c17
Commit Message: dynamic_modules: scaffolds config API & HTTP Filter
Additional Description:
This scaffolds the configuration API marked as work-in-progress, and
the skeleton HTTP filter implementation based on the configuration.
The real implementations will follow after this commit.
Risk Level: low
Testing: done
Docs Changes: n/a
Release Notes: n/a (not enabled yet)
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e6450aac2d0010555c82eb1ff513cf234ab5817
For https://github.com/istio/istio/issues/53577
I'm trying to configure DNS resolvers (specifically
`CaresDnsResolverConfig.udp_max_queries`) while using the default system
resolvers. Right now, I need to add one resolver, otherwise I get a
proto validation error.
Commit Message: Allow empty resolver list for cares dns
Additional Description:
Risk Level: low
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
Signed-off-by: Steven Jin Xuan <sjinxuan@microsoft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 27083e8f153a074f6a26428f84444ce213b3fbd0
Commit Message: add a config knob to Java, Kotlin and C++ engines to set
initial interval of QUIC keepalive probing.
Additional Description: also adjust the validation rule of
`initial_interval` to be larger than 1ms instead of 1s and fix
contradicting documentation.
Risk Level: low, interface change
Testing: unit test
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
---------
Signed-off-by: Dan Zhang <danzh@google.com>
Co-authored-by: Dan Zhang <danzh@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ fe8bc08a2201567833b0245526018f5480cd8cb1
Commit Message: aws_signing: support for dynamically configurable
credential
Additional Description:
This adds a new API for AWS Signing filter that allows control planes to
configure the credentials providers to sign requests.
Note that the similar configuration had already been added for AWS
Lambda filter,
and this adds the similar but more generic configuration API for
credential in the common
configuration. In the future, the lambda filter can also leverage this
new common
configuration.
Closes#36109
Risk Level: low
Testing: unit
Docs Changes: done
Release Notes: done
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 871b3e91234d6e305d4ec653444f1d56b324a302
Commit Message: remove WIP annotation. unified matcher has been used in
production for quite a while
Signed-off-by: tyxia <tyxia@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d049362557545b054e1a883231e64944ed0a8819
http_11_proxy: Make inner transport_socket config optional
Given that the top-level
[Cluster.transport_socket](1a153166a6/api/envoy/config/cluster/v3/cluster.proto (L1099))
field is optional and defaults to plaintext, this should also be
optional. gRPC is adding support for this transport socket, but they do
not have a `raw_buffer` to explicitly configure. See
https://github.com/grpc/proposal/pull/455#discussion_r1776143739 for
additional context.
Risk Level: Low.
Testing: Existing tests.
Docs Changes: n/a
Release Notes: Done.
---------
Signed-off-by: Tony Allen <txallen@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c6761de5f33e97758471c6b973a57a5c2e5db925
Commit Message: local rate limit: add new rate_limits api to the
filter's api
Additional Description:
In the previous local rate limit, the
[rate_limits](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-field-config-route-v3-virtualhost-rate-limits)
field of route is used to generate the descriptor entries. Then the
generated entries will be used to match a token bucket which is
configured in the filter configs (route level, vhost level, etc).
However, it make the configuration very complex, and cannot cover some
common scenarios easily. For example, give a specific virtual host X and
a special route Y that under this virtual host X.
We want to provides a virtual host level rate limit for the specific
virtual host X, and a route level rate limit for the specific route Y.
We hope the configuration of virtual host could works for all routes
except the Y.
For most filters, this requirement could be achieved by getting the most
specific filter config and applying it. But for the local rate limit,
thing become very complex. Because the rate limit configuration is split
into `rate_limits` field of route and the filter config. The local rate
limit need to handle these relationship carefully.
This PR try to simplify it.
Risk Level: low.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.
---------
Signed-off-by: wangbaiping <wangbaiping@bytedance.com>
Signed-off-by: code <wbphub@gmail.com>
Co-authored-by: Matt Klein <mattklein123@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ e48666365c8a0b3a62343602fd9380d58a7afd95
Also, update docs and tests for similar runtime overrides that already
existed
This is a followup to #36231
Risk Level: Low
Testing: New tests, plus more tests for existing untested code
Docs Changes: Updated proto docs, including adding docs for existing
feature
Release Notes: updated
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1173629e531abf758f011c2da15da739f72881c6
Commit Message: xds: make certificate provider instance name required
Additional Description: The comment saying that there is a default value
for this field is misleading. All existing gRPC implementations have
this as a required field. Note that this change does not affect Envoy,
since Envoy does not yet support this field. However, I've added a PGV
annotation (used by Envoy but not by gRPC) to avoid confusion when Envoy
eventually adds support for this field.
Risk Level: Low
Testing: N/A
Docs Changes: Included in PR
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Mark D. Roth <roth@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 42068a59e37d0d6c313340d0175cb08cce2574bb
Risk Level: low
Testing: n/a
Docs Changes: n/a
Release Notes: inline
Fixes:
Description:
This is to address the issue:
https://github.com/envoyproxy/envoy/issues/35488, i.e, integrate the
ext_proc HTTP client to ext_proc filter. With this PR, the basic
functionalities to have Envoy ext_proc filter talk to a HTTP server
using HTTP messages are accomplished.
This is the follow up of PR:
https://github.com/envoyproxy/envoy/pull/35676
---------
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ a3e32c92c5ae699a4daad094c6a87b58e1e84ec2
**Commit Message:**
oauth filter: set token cookies regardless of forward_bearer_token
option + ability to disable refreshtoken and bearertoken cookie
**Additional Description:**
Unconditionally set the BearerToken, IdToken, and RefreshToken cookies
in the response. The documentation of forward_bearer_token states
"Forward the OAuth token as a XXX to upstream web service." It's
confusing for this behavior to affect response cookies as well.
This change alone would set the raw bearer token in the client browser
which is undesirable by some.
Therefore introduced further properties to disable single cookies, if
necessary:
* `disable_access_token_set_cookie`
* `disable_refresh_token_set_cookie`
Like it was done here: https://github.com/envoyproxy/envoy/issues/33825
Risk Level: Low
Testing: Included
Docs Changes: N/A
Release Notes: Included
Platform Specific Features: N/A
Fixes: https://github.com/envoyproxy/envoy/issues/32566
---------
Signed-off-by: Dennis Kniep <kniepdennis@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 46e8da9d1b01ecf120d503bd0449a3041cb63399
Commit Message:
When Envoy operates as a CONNECT-UDP forwarding proxy, it was resetting
the upstream stream because it received HTTP Datagrams before receiving
the SETTINGS frame. A new enum has been added in QUICHE to distinguish
this case, so I added handling logic for this and made Envoy drop the
datagrams instead of resetting the stream.
Also, Envoy was dropping Datagrams because the default maximum packet
length for QUIC connections in QUICHE is not large enough for tunneling
use cases such as CONNECT-UDP. I added a new QUIC protocol option called
`max_packet_length` to allow users to adjust the maximum packet length
for upstream QUIC connections to fix this issue.
Additional Description:
Risk Level: Low, this change is only relevant if CONNECT-UDP is enabled
with the forwarding mode.
Testing: Added more unit tests.
Docs Changes: Added the `max_packet_length` QUIC protocol option and its
explanation.
Release Notes: Added notes about fixing the CONNECT-UDP forwarding mode
and adding the new QUIC protocol option.
Platform Specific Features: N/A
[Optional Fixes #Issue]: #34836
---------
Signed-off-by: Jeongseok Son <jeongseok.son@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e7fdf5f23e3147a998c24a0cf8e3192797e80c5
This is a minor change to unblock config plane work while #35905 is
going through review. See #35905 for initial LB policy implementation.
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
Part of #34777
Signed-off-by: Misha Efimov <mef@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 135a6a29c16eacf46fdc8f1a87b4864e3c403eb6
<!--
!!!ATTENTION!!!
If you are fixing *any* crash or *any* potential security issue, *do
not*
open a pull request in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged
appropriately.
Thank you in advance for helping to keep Envoy secure.
!!!ATTENTION!!!
For an explanation of how to fill out the fields, please see the
relevant section
in
[PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
-->
Commit Message: basic_auth: support authorization header override
Additional Description: provide a way to do basic authorization on
headers other than `:Authorization`. Say we are doing two level of basic
authorization. One at the proxy level with header name
`Proxy-Authorization` and the other one at the application level with
header name `Authorization`.
Risk Level: low
Testing: unit test
Docs Changes: changelog
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: Networking team <networking@lyft.com>
Co-authored-by: Networking team <networking@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ f3ff3306f53fc0ebb6314ffad947896b56b23d29
Commit Message: Implementing reject_new_connections QUIC listener
option.
Additional Description: The goal is to implement a mechanism to
configure the bootstrap to reject H3 traffic as early as possible in the
QUIC layer. This is done by replying to the client with an empty QUIC
version negotiation packet to leverage the incompatible version
negotiation logic from RFC 9368. This feature is off by default.
Risk Level: Low
Testing: UTs
Docs Changes: N/A
Release Notes: added new_features/quic note
---------
Signed-off-by: Ricardo Perez <ripere@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 88543c9c37f389ff6d2650bb7aae211563ab0485
Commit Message:
Followup changes for `OrcaLoadReport` handling in `Router::Filter`.
- Use ENVOY_STREAM_LOG in `Router::Filter::maybeProcessOrcaLoadReport`.
- Add Integration test for custom metrics.
- Update CNCF version to bring in `OrcaLoadReport` proto changes.
- Add references to `OrcaLoadReport` proto.
Risk Level: low
Docs Changes:
Release Notes:
#34777
---------
Signed-off-by: Misha Efimov <mef@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4ba73c869963cbf1d1afe8f4a4f568783fb1c750
Commit Message: ext_authz: add logging options / stats
Additional Description:
logging_options enables ext_authz to emit per-stream stats through
filter state for access logging. The stats emitted depend on the client
used.
If envoy GRPC is used, latency, bytes sent, bytes received, upstream
host, and cluster info are emitted. Otherwise, only latency is emitted.
If logging_options.filter_metadata is present, ext_authz will also emit
the filter metadata in its logging info.
ext authz will only emit stats & and filter metadata if a request is
made.
Testing: unit & integration tests
Docs Changes: none
Release Notes: changelog updated
Platform Specific Features: n/a
---------
Signed-off-by: antoniovleonti <leonti@google.com>
Signed-off-by: Antonio V. Leonti <53806445+antoniovleonti@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1eedeeed1a421f15577733347e8a32c1ace1f953
Commit Message: Add a CPU utilization resource monitor for overload
manager. i.e. this can be configured to reject requests once CPU Utilization reaches a certain brownout point.
Signed-off-by: Can Cecen <ccecen@netflix.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4d121628c648d2f565b4e6651484036981051763
Commit Message: xff: add support for configuring a list of trusted CIDRs
The original client IP address can be determined from the
x-forwarded-for header either by a fixed number of trusted hops, or by
evaluating the client IP address against a list of trusted addresses.
This adds support for configuring a list of CIDRs in the xff original IP
detection extension. The remote IP address is evaluated against these,
and optionally recurses through XFF to find the last non-trusted
address.
Additional Description:
This feature is generally used by people with a CDN in front of their
edge proxy to ensure that XFF is only parsed when the remote connection
comes from a CDN server.
The behaviour of the new functionality should be the same as Nginx's
`realip` module.
Disclaimer: This is my first time writing C++ so I'm not certain my
changes are completely idiomatic, but I've tried to stick with existing
style in the codebase. Feedback very welcome!
Risk Level: Medium
Testing: Unit tests, manual tests
Docs Changes: Updates to HTTP Connection Manager header manipulation
docs, and proto docs.
Release Notes: Added to changelogs/current.yaml
Platform Specific Features: None
Fixes#21639
Relates to #31296
---------
Signed-off-by: James O'Gorman <james@netinertia.co.uk>
Mirrored from https://github.com/envoyproxy/envoy @ fbc6ee2ed5b858c842999c688504fd133008868a
Add clarifications to the proto documentation.
---------
Signed-off-by: Tony Allen <txallen@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1130fca31d99f9c7ceff7fd0a1d2c4ee8ca25064
…33875)"
This reverts commit bf65ad3ab24a6c3cb2b60cdb2e043dea6e32c2ac.
Fix#35653
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ b7e13f1d806f244da5fef2578e61c1e06a12fb33
Commit Message: Add retry policy to the OAuth2 filter to avoid failing
to call the Authorization server.
Additional Description:
Some EG users reported that Authorization servers may timeout TCP
connections in the pool but only send an RST when Envoy reuses a
connection to send a request to the Authorization server again. This
behavior causes the authentication flow to fail. Implementing retries
can mitigate this issue.
Risk Level: low
Testing: unit test, integration test
Docs Changes: API
Release Notes: yes
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue] Fixes:
https://github.com/envoyproxy/envoy/issues/33572
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
Related EG issue: https://github.com/envoyproxy/gateway/issues/3178
Caveat: I'm not very experienced in c++, so some of my implementation
may not adhere to the best practice of c++ or the conventions of Envoy
codebase. I welcome any feedback and will consider it a valuable
opportunity to learn the right way to contribute to Envoy. Thank you!
---------
Signed-off-by: Huabing Zhao <zhaohuabing@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7f231c139f2c2a74d79fad98f21781a715ae5bae
Adds a configuration to set the number of retries in `getaddrinfo`
resolver. If the `num_retries` is set, the resolver will retry up to
`num_retries` when `getaddrinfo` returns `EAI_AGAIN`. If `num_retries`
is not set, the resolver will retry indefinitely until it succeeds or
the DNS times out to keep the behavior the same as the current behavior.
Risk Level: low (a new feature)
Testing: unit tests
Docs Changes: inline
Release Notes: inline
Platform Specific Features: n/a
Runtime guard: `envoy.reloadable_features.getaddrinfo_num_retries`
---------
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9cb48c2d9095562c64ada207660ca7a38ca62992
The Proto Message Extraction Filter supports extracting gRPC
requests/responses (proto messages) as `google.protobuf.Struct` and
storing results in the dynamic metadata
`envoy.filters.http.proto_message_scrubbing` for later access.
---------
Signed-off-by: dchakarwarti@google.com <dchakarwarti@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 16759b97e02131cc9c8ca64d13cf663c75dae047
update-envoy[bot]