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
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
update-envoy[bot]