Commit Message: support backoff between retries in udp_proxy
Additional Description: This feature also fixes a bug in the retry
mechanism in udp proxy in the following situation:
1. We are tunneling UDP over HTTP.
2. A new stream is created on existing upstream connection
(multiplexing) and waiting for response headers.
3. The upstream connection is closed.
4. During the close process, all streams created on this connection will
be reset.
5. The udp_proxy receives a callback on the stream reset.
6. They retry to connect.
7. The closed connection is picked as it is still in the connection pool
(we are still in the process of the close).
8. The new stream that is created on the second attempt will be reset
immediately.
9. The same process will happen (step 5 - step 8) until we reach the
max_connect_attepts.
10. This means that we are doing only one real attempt in this
situation.
Risk Level: medium
Testing: unit tests, integration tests
Docs Changes: added
Release Notes: added
---------
Signed-off-by: Issa Abu Kalbein <iabukalbein@microsoft.com>
Co-authored-by: Issa Abu Kalbein <iabukalbein@microsoft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 24254316bab17cb48d48f88297e91a3dee739f58
Reapply the RBAC change by reverting
https://github.com/envoyproxy/envoy/pull/35899.
The original commit is reverted for flaky RBAC integration test.
The fix is pretty simple by just removing the simulated time in the test
([diff](d3297b4aa6)),
I'm not sure of the root cause but the test does not really need the
simulated test.
Before the fix, the flaky test can be reproduced easily with
`--runs_per_test=1000`, After the test, I can no longer reproduce
the failure. To be on the safer side, I ran the test with
`--runs_per_test=10000` and still couldn't reproduce the test failure.
Test output:
```
% bazel test //test/extensions/filters/network/rbac:integration_test --runs_per_test=10000 --test_timeout=60 --test_env=ENVOY_IP_TEST_VERSIONS=v4only
INFO: Invocation ID: c1ebbc18-4887-4626-9d19-e257d42fe4cd
INFO: Analyzed target //test/extensions/filters/network/rbac:integration_test (0 packages loaded, 19 targets configured).
INFO: Found 1 test target...
Target //test/extensions/filters/network/rbac:integration_test up-to-date:
bazel-bin/test/extensions/filters/network/rbac/integration_test
INFO: Elapsed time: 2486.472s, Critical Path: 24.73s
INFO: 10001 processes: 1 internal, 10000 processwrapper-sandbox.
INFO: Build completed successfully, 10001 total actions
Executed 1 out of 1 test: 1 test passes.
```
---------
Signed-off-by: Yangmin Zhu <ymzhu@uber.com>
Mirrored from https://github.com/envoyproxy/envoy @ 72854250164014b5b179ee5c9b4c4b88d8bba38c
Created by Envoy dependency bot for @phlaxFix#37778
Signed-off-by: dependency-envoy[bot] <148525496+dependency-envoy[bot]@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2aa8a14d646234c36c9a8267a3caeb5485501001
Commit Message: xDS: add enum specified in xRFC TP3 in the right place
Additional Description: In #37818, I incorrectly added this new value to
the deprecated location for this enum, not the real location. :(
Risk Level: Low
Testing: N/A
Docs Changes: Included in PR
Release Notes: N/A
Platform Specific Features: N/A
CC @adisuissa
Signed-off-by: Mark D. Roth <roth@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f7a86358aeaa1627c43da8ebfddb9a94d525166a
## Description
This PR adds some more description around `use_independent_randomness`
to make it more user-friendly and clarify other fields.
<img width="991" alt="Screenshot 2024-12-23 at 01 20 20"
src="https://github.com/user-attachments/assets/5d1a1532-3f47-49bc-87c0-cf5189a2877f"
/>
---
**Commit Message:** docs: clarify the docs on runtime_filter
**Additional Description:** Added some more description around
`use_independent_randomness` to make it more user-friendly.
**Risk Level:** Very Low
**Testing:** N/A
**Docs Changes:** N/A
**Release Notes:** N/A
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ f1228663ff631ea95ef7d464de6efa898fbd430a
Commit Message: ratelimit: option to excute action on stream done
Additional Description:
This adds a new option `apply_on_stream_done` to the rate limit
policy corresponding to each descriptor. This basically allows to
configure
descriptors to be executed in a response content-aware way and do not
enforce the rate limit (in other words "fire-and-forget"). Since addend
can be currently controlled via metadata per descriptor,
another filter can be used to set the value to reflect their intent
there,
for example, by using Lua or Ext Proc filters.
This use case arises from the LLM API services which usually return
the usage statistics in the response body. More specifically,
they have "streaming" APIs whose response is a line-by-line event
stream where the very last line of the response line contains the
usage statistics. The lazy nature of this action is perfectly fine
as in these use cases, the rate limit happens like "you are forbidden
from the next time".
Besides the LLM specific, I've also encountered the use case from the
data center resource allocation case where the operators want to
"block the computation from the next time since you used this much
resources in this request".
Ref: https://github.com/envoyproxy/gateway/issues/4756
Risk Level: low
Testing: done
Docs Changes: done
Release Notes: TODO
Platform Specific Features: n/a
---------
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 857107b72abdf62690b7a1c69f9a3684d57f5f3e
Commit Message: api: new per descriptor hits-addend support and dynamic
hits addend
Additional Description:
1. Now, we could get custom hits_addend from the
`envoy.ratelimit.hits_addend`. But if there are multiple rate limit
filters that requrie custom hits_addend, the
`envoy.ratelimit.hits_addend` couldn't meet the requirement.
2. And we cann't also to support different hits_addend for diffferent
descriptots in same request.
This API changes try to meet above two requirements.
Risk Level: low.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.
---------
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Mirrored from https://github.com/envoyproxy/envoy @ cac9b87e9c0cd10eafc64817130c27c567395f4d
The gRPC JSON reverse transcoder acts as a bridge between gRPC client
and an HTTP/JSON server, converting the gRPC request into HTTP/JSON or
the HTTP backend and the HTTP/JSON response back to gRPC for the gRPC
client.
**Risk Level:** Low
**Testing:** Added unit and integrations tests.
**Docs Changes:** Nil
**Release Notes:** Nil
**Platform Specific Features:** Nil
---------
Signed-off-by: numanelahi <numanelahi@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b846d18527cf0867dcfd316c4323ea26fab78f9d
## Description
I noticed that some of the sections of the TLS Context docs are very
verbose and hard to read. This PR is to make it a little bit more
user-friendly.
<img width="939" alt="Screenshot 2024-12-10 at 11 54 52"
src="https://github.com/user-attachments/assets/0d0bb6b2-959b-41d2-abe6-106029164f04">
---
**Commit Message:** docs: refactor TLS Context docs to make it more
reader friendly
**Additional Description:** Refining the TLS context docs to make it
more user-friendly.
**Risk Level:** N/A
**Testing:** N/A
**Docs Changes:** N/A
**Release Notes:** N/A
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Co-authored-by: phlax <phlax@users.noreply.github.com>
Co-authored-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ d9ab49674771ddafc077d29ff8a29ebe8ab762b6
Following on from https://github.com/envoyproxy/envoy/pull/24070 and
adding support for week as a unit of time for ratelimits as this is
something my team currently needs and WEEK felt sad as it was missing
the protobuf party.
Ideally we would have something like
https://github.com/envoyproxy/envoy/issues/33277 but in the interim it
makes sense to add WEEK here since we have every other period already
except week.
Signed-off-by: Stefan Sedich <stefan.sedich@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 33fb49977a10657a84a4aff1ea8c7988c54e3c42
Related to #37545
Signed-off-by: Ryan Northey <ryan@synca.io>
Co-authored-by: dependency-envoy[bot] <148525496+dependency-envoy[bot]@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ cb46fd4ce20d38b647ac5ef3d5fb92d9146ccde6
- populate rules_cc information in bazel/repository_locations.bzl
- load rules_cc in repositories.bzl
- stop listing rules_cc as an untracked dependency of rules_rust
Before this, we didn't track `rules_cc` at all, and were at the whim of
whatever brought it in, which for a local build for me today was 0.0.4,
from circa 2022.
This does introduce some noise as the `cc_proto_library` rules in
`rules_cc` now delegates to the one from `@com_google_protobuf` with a
deprecation warning. We can silence these with a few small patches to
our dependencies to bring them up to date if just updating them is
insufficient.
Risk Level: low
Testing: ci
---------
Signed-off-by: Alejandro R. Sedeño <asedeno@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 223443a07ac1ab1aa5a0dfe5cf664d1d7ab65d26
Additional Description: This has been deprecated for several releases,
and the upstream dependency is no longer maintained.
Risk Level: Low; this was marked as deprecated in 1.28 and was supposed
to be removed in 1.30
Fixes#9958
Progress on #11816
---------
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Co-authored-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ e456b9ba7683a09cea7a7f2af6d3a5a5c2ac10a6
I noticed some minor mistakes in ExtAuthZ's documentation where certain
words are duplicated and inconsistent style is used for some words like
`gRPC` (Also spelled GRPC and grpc). This PR is fixing these nits.
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Co-authored-by: phlax <phlax@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 61c7b3ceafee1a118e3af3e8b63516fd4244c9ac
Commit Message:
Add `ConnectionPoolSettings` in proxy_protocol upstream transport
socket.
It customizes the behavior of connection pool.
Additional Description:
Risk Level: LOW
Testing: CI
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
Fixes#37126
[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: Yuchen Dai <silentdai@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5f089ddbc962cc0bfe94ad24f20459ff8cecb4bf
Commit Message: Save resolved upstream address in filter state in SNI
dynamic forward proxy
Additional Description:
Risk Level: Low
Testing: Added unit tests and am also consuming this change from filter
state in a subsequent filter
Docs Changes: Fixed a typo in doc and added new field to proto
Release Notes: Added a description in change log
Platform Specific Features:
Signed-off-by: Santosh Rao <santosh.bl@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7975a2b760c55dba724bd6c5dba2909e86aa309c
This PR adds field access support for ext_authz filter state object
`ExtAuthzLoggingInfo`. It exposes simple fields
* latency
* bytesSent
* bytesReceived
This enables usage of ext_authz filter state in access logs, and any
filter/logger using CEL after
https://github.com/envoyproxy/envoy/pull/35698.
Signed-off-by: JACQUES Francois <hypnoce@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 004e6eeaa6b4066f2ba62ca440bbcfb9fb3bc228
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
update-envoy[bot]