**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
resolves#35673
## PR overview
Redis proxy users may want to create advanced authentication methods.
For example, the official [Azure SDK extension for
Redis](https://github.com/Azure/Microsoft.Azure.StackExchangeRedis)
allows to authenticate to a Redis server using Microsoft Entra ID
token-based authentication, by passing a token in the password argument
of the `AUTH` command periodically, based on token expiration.
This PR introduces a way to support external authentication via a gRPC
service with additional support for expiry of such authentication (e.g.
for token-based authentication).
This way we keep it extensible for **any** advanced authentication
methods users might want to develop.
### The reviewer may ask: Why not use the _ext_authz_ filter?
The cost/latency impact by using the _ext_authz_ filter is much bigger
than the proposed design. That's because instead of being called on
every request, the current design only calls the external dependency on
**AUTH** commands. Not only that, but also we would have to decode the
Redis protocol twice, if we used a separate filter.
---
Risk Level: Medium (small optional feature added to existing filter)
Testing: ✅
- Unit Tests
- Integration Tests
- Manual Testing
- Also, we are already using the signed _-dev_ build on a test AKS
cluster
Docs Changes: ✅
- Proto docs
- Updated authentication-related information on the Redis protocol page.
Release Notes: ✅
---------
Signed-off-by: Diogo Barbosa <diogobarbosa@microsoft.com>
Signed-off-by: Diogo Barbosa <pessoal.dbarbosa@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 67b69c9038402b88953a2ab171ae38cab5cb23ab
Commit Message: Allow specified UDP cmsg to be saved to
QuicReceivedPacket
Additional Description: This can be accessed via
QuicListenerFilter::onFirstPacketReceived.
Risk Level: Low
Testing: Integration test
Docs Changes: N/A
Release Notes: added
---------
Signed-off-by: Paul Sohn <paulsohn@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ bd5bec9abb537b3d462ed4e74bb5ea4bf1844655
<!--
!!!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)
-->
ProtobufWkt::Value is introduced by #35162
Commit Message:
Additional Description:
Risk Level: low
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
Signed-off-by: Boteng Yao <boteng@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 77357cac6e6fd1dc4d91884a7cb93156f6e2feb7
Resolves#35641. Adding DNS jitter to resolvers makes it so that envoy
doesnt stampede the DNS server when it has multiple entries with the
same expiration.
Testing is still WIP. I am open to any suggestions.
Commit Message: dns: add jitter to strict dns
Additional Description:
Risk Level: low
Testing: unit tests
Docs Changes:
Release Notes:
for the :ref:`strict DNS
<arch_overview_service_discovery_types_strict_dns>` and :ref:`logical
DNS
<arch_overview_service_discovery_types_logical_dns>` cluster types,
the new :ref:`dns_jitter
<envoy_v3_api_field_config.cluster.v3.Cluster.dns_jitter>` field, if
provided, will causes the cluster to refresh DNS entries later by a
random amount of time as to
avoid stampedes of DNS requests. This field sets the upper bound
(exclusive) for the random amount.
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>
Signed-off-by: Steven Jin <stevenjin8@gmail.com>
Co-authored-by: Adi (Suissa) Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 20e27887d29d735e1cc47cbb9af1cfe9baac4b4d
Commit Message: GrpcFieldExtraction: Supports extracting fields of type
`map<string, string>` in addition to string
Additional Description:
Risk Level: Low
Testing: Unit test
Docs Changes: Inline with the filter API proto.
Release Notes: This change is backward compatible and no behavior change
is expected for existing users.
Platform Specific Features:
---------
Signed-off-by: Xi Wu <xiwuxw@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1cd67c5821125a246e2a4f13254f8d6c69068705
Previously the only way to configure the HTTP/1.1 proxy transport socket
was by adding information to the streamInfo metadata via an intermediate
filter. This patch adds the ability to configure proxy addresses using
endpoint or locality metadata.
The metadata key is `envoy.http11_proxy_transport_socket.proxy_address`.
Configuration can be set in the metadata associated with
`LocalityLbEndpoints`. The metadata associated with each individual
endpoint overrides this value and the original method of configuration
(filter state metadata) takes precedence above all. The format of the
value must be a valid `config::core::v3::Address`.
Risk Level: Low. Alpha feature.
Testing: Unit test.
Docs Changes: Done.
Release Notes: Done.
---------
Signed-off-by: Tony Allen <txallen@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 03561251fbc50e9d16b35e02ae6032e073c16430
This PR adds an option to change the http connection manager's draining
behavior for max_connection_duration for http1. The new behavior is that
envoy will wait indefinitely for one more request, add connection:close
to the response headers, then close the connection once the stream ends.
This is to avoid a networking race condition which results in the client
not receiving a response to their last request if they send it right
when envoy is closing the connection.
Fixes#34356 (check for context)
---------
Signed-off-by: antoniovleonti <leonti@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5b22dced91c062fc409153777c287f053dac0cbe
<!--
!!!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: Adds the ability to set the hits_addend for a given
rate_limit request via a hardcoded dynamic metadata field:
envoy.ratelimit:hits_addend.
Additional Description:
Risk Level: Low
Testing: Added unit test. I have also manually tested this using
gloo-edge as the control-plane.
Docs Changes:
Release Notes:
Platform Specific Features: N/A
[Optional Runtime guard:] N/A
[Optional Fixes #Issue] N/A
[Optional Fixes commit #PR or SHA] N/A
[Optional Deprecated:] N/A
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
N/A
---------
Signed-off-by: Eitan Yarmush <eitan.yarmush@solo.io>
Signed-off-by: code <wbphub@gmail.com>
Co-authored-by: code <wbphub@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9a474a30a1b9ecbfe1e9d1a5190ee8aef2b29041
update-envoy[bot]