Modifies the well-known-names of the built-in stat sinks and
tracers to use the same name as the extension build system.
Risk Level: low, previous name is still accepted
Testing: existing tests + deprecated tests for old names
Docs Changes: updated names
Release Notes: updated
Deprecated: old names are logged as deprecated
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ b09184f8e9e17839f555f78ad8dbbcc57e3709db
Modifies the well-known-names of the built-in access loggers to
use the same name as the extension build system.
Risk Level: low, previous name is still accepted
Testing: existing tests
Docs Changes: updated names
Release Notes: updated
Deprecated: old names are logged as deprecated
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9cc7a5caf2961947d6c5eea18a1afbbbc13af82b
This new alpha filter injects authentication headers for requests
directed at AWS services that require authentication.
Note:
Requests over plain HTTP aren't handled yet, since the message body
needs to be signed.
Fixes#9708
Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ ee2306673b79215641be02893cb4d8b2b256c466
In ext_authz HTTP implementation, when user set content-length as one of
the allowed headers patterns as part of request authorization, we should
skip setting it since it is already configured at initialization and the
value depends on the request_size.
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ aaf67bba8c0fd245dbdd41b7c9eef6639ecbfa0d
Currently supported retry host predicates only allow omitting either previously tried or canary hosts. This enhancement is to add a new host predicate that looks at the endpoint metadata match and omits the host in case of a match with the host metadata. See #9531
Risk Level: Low
Testing: Unit testing
Docs Changes: Added new proto for omit_hosts
Signed-off-by: Prakhar Gautam <prakhag@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ e2fdf70f0fca0f9a9a66046fd80b280981b3f0ed
This PR introduces a parallel v3 API reference documentation tree to the
existing v2 one.
The docs/root/api-v3/ tree was copied from docs/root/api-v2 and the
necessary package path fixups were made manually. As a result, the tree
largely resembles the v2 docs. Long term this is likely to evolve to
reflect the shape of the new extensions tree.
The message type, field and enum anchors are sed'ed to be distinct and
self-consistent inside api-v3/.
There were a number of API proto changes that were made to obtain a
successful Sphinx build:
* References to deprecated fields were replaced by references to the replacement field.
* clang-format line wrapping in protoxform was removed, this breaks RST in some v3 protos.
* Some packages (type/metadata/v2, data/cluster/v2alpha) were force upgraded to v3, to deal with references to types that are distinct in v2/v3. This is OK as these packages probably make sense to bump for v3, in general we're going to have to think about how to do this more
cleanly, supporting dual v2/v3 references alongside each other.
* Some evil hacks for field renaming added to migrate.py for RouteAction.
There's also some additional machinery added to compute distinct v3/v3
build targets to point protodoc at.
Risk level: Low
Testing: Docs build, manual inspection.
Fixes#8087
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ac88316892cd47b6a9b58e3736e20e8863cd0d27
Description: this PR introduces the initial implementation of an Api Listener based on the proto configuration merged in https://github.com/envoyproxy/envoy/pull/8170. Notably, this PR introduces the ability to add only _one_ api listener via _bootstrap config only_. This decision was made in order to iterate into more complex setups (multiple listeners, LDS supplied listeners) in subsequent PRs. Moreover, the API listener is created in the context of Envoy's main thread not worker threads.
A first use of this Api Listener can be seen in https://github.com/lyft/envoy-mobile/pull/616.
Risk Level: low, only used in Envoy Mobile. The risk here is about building something generally useful and flexible. Note however that a couple of things were rejiggered in the HCM.
Testing: unit and integration tests. Additional testing in https://github.com/lyft/envoy-mobile.
Docs Changes: Added inline comments and TODOs. Proto documentation is up-to-date.
Release Notes: similar to doc changes.
Signed-off-by: Jose Nino <jnino@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9b6260fcf6ee1299744b8e5c76c1e6d9d36f7c89
This is expected behavior, but just lets add a note to
RequestMirrorPolicy as a reminder.
Fixes#9698
Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ 552a42d6cd12fbde790c0f5664a1141e37c160e1
In which we convert every v3alpha reference to v3. In future revs of the
stable API versioning policy, we will develop better tooling to support
> 2 alpha and stable versions. For v3, it seems reasonable to just mv
v3alpha to v3, since there should be no external consumers yet.
Risk level: Low
Testing: bazel test //test/..., CI.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
This PR makes the following fatal by default:
from cluster.proto: ORIGINAL_DST_LB, tls_context, extension_protocol_options
from health_check.proto: use_http2
from route_components.proto: allow_origin regex, pattern, method, regex_match, value
from http_connection_manager.proto: operation_name
from trace.proto: HTTP_JSON_V1
from string.proto: regex
Risk Level: Medium (who knows who is using them)
Testing: test framework updates
Docs Changes: n/a
Release Notes: n/a
Originally #8847
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 33100e8bbeca057e23d07e46e42c51376700f872
Now that we have stable Envoy API versioning, deprecate in v2, with the
understanding that we won't ever make this a runtime controlled field.
Risk level: Low
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ab965195f6e238b5b66312497b19e9503f22cfb2
Changing from relative name to absolute name, and fixing the fatal-by-defaults that were broken by the v3 switch.
The old way to allow fatal-by-defaults was
envoy.deprecated_features:proto_file.proto:field_name
the new way is
envoy.deprecated_features:full.namespace.field_name
When we switched to v3, all the hard-coded v2 names stopped working. This reinstates them via hopefully more permanent proto annotation.
The only remaining ugly bit is that unfortunately the full namespace and field name are the v3 versions even if the original config was v2. Between @htuch and I we should fix that before merging.
Risk Level: Medium
Testing: added new unit tests
Docs Changes: updated
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 156d7c90083c196a206c07fc03b2de6be8260bd3
Add support for per-route configurable maximum number of internal redirect hops
Risk Level: Medium
Testing: Unit and integration tests added / modified
Docs Changes: Described the new field in intro/arch_overview/http/http_connection_management.rst
Release Notes: Added
Fixes#9144
Signed-off-by: Peng Gao <pengg@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1f208984f1eb6253c3f2ee49139831f6766b673e
This is a followup to #9301, where it was not possible to deprecate a
field on DiscoveryRequest as we were previously assuming identical v2/v3
transport protocols. After this deprecation, build_version can't appear
in v3 messages, and we need to convert back to a true v2
DiscoveryRequest prior to JSON serializing for REST.
There's more work to be done in the future, when we add new v3-only
fields, but this should work for 1.13.0. Future work tracked at
https://github.com/envoyproxy/envoy/issues/9619.
Risk level: Low
Testing: coverage of the behaviors for both gRPC and REST config sources
is provided by api_version_integration_test (failing previously as soon
as build_version was deprecated).
Fixes#9604
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0ee6212b02bdab7b3d66e868449ac93556e63118
Implements on-demand resolution of VirtualHosts via VHDS
Signed-off-by: Dmitri Dolguikh <ddolguik@redhat.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8e2d909ad22f84d9eb055f06890924a5879bad76
This change adds a pair of histograms to track timeout budget usage: one for the
per-request timeout and one for the global timeout. The histograms are scaled
such that 100% of the timeout budget is a value of 10000 so that four digits of
the percentage used can be recorded.
Risk Level: Low (new stats only).
Testing: Unit tests added/modified.
Docs Changes: Added notes about historgrams.
Release Notes: Added comment with link to docs.
Fixes#6122
Signed-off-by: Matthew Gumport <mgumport@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ ebab713091fc21818d229e1f9f99b1ee8334eb87
Description: add auto_sni flag on cluster that executes to change sni field on sni field automatically.
Risk Level: Low
Testing: Unit Test
Docs Changes: Added
Release Notes: Added
Signed-off-by: shikugawa <rei@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 18ec59136e7a265556ca1d660dd7eb103182ea3a
This patch introduces a new checker, tools/api/validate_structure.py, that is run as part of the
bazel.api CI job. It ensures that the package layout for the API doesn't violate some constraints,
largely reflecting the heuristics we used for v3alpha migration.
Along the way, I discovered there were some packages that were versionless and not boosted to
v3alpha, and there were some extensions left behind in envoy.config. These are fixed as well to
allow the validation to succeed.
Risk level: Low
Testing: tools/api/validate_structure.py passes, bazel test //test/...
Fixes#9580
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 29b30911dbfb3f9760efeb28238ceac36e1a1a23
Report extension information in the Node message.
Risk Level: Low
Testing: Unit Tests
Docs Changes: N/A
Release Notes: N/A
Fixes: #8332
Signed-off-by: Yan Avlasov <yavlasov@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f5efe4a9bedf0ef7b03324f9bfda50118a0555c4
Define empty config protos for all filters expecting google::protobuf::Empty
Risk Level: medium (change of config type)
Testing: unit
Docs Changes: done
Release Notes: define config protos for all extensions
Co-authored-by: Derek Argueta <dereka@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2d5a4e94720cc195324f79ca68f0e7a7dc83ee9e
This PR extends #9468 to support a distinct notion of transport and
resource API version. The intuition here is that the opaque resources
(and their type URLs) can be delivered via either v2 or v3 xDS, and the
DiscoveryRequest etc. messages have their own versioning.
Currently, the v2 and v3 transport protocols are indistinguishable
modulo service endpoint. As v3 evolves, e.g. with #9301, differences
will be introduced. At this point it will be necessary to have enhanced
support in the gRPC mux and HTTP subscription modules to handle the
protocol differences.
This is technically a breaking v2 API change, but since the field it
breaks was only added today, I think it's safe to assume it is not in
use yet.
Risk level: Low
Testing: Integration tests added to validate service endpoint and type
URL selection based on transport/resource version.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ df0582765f8cc01a2f5901b068783f6bba9366f0
Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ a60f6853a2c2ebbbfed79dfff0b5b644fd735980
This allows for a clean separation of config/service in v3. This is a
continuation of #9548.
Risk level: Low
Testing: bazel test //test/...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c3bddaee1912fcd1fedc4786aee830b2e4a7c599
Description:
Move packages around for #8120 and #8121
Risk Level: Med around messing up build.
Testing: CI
Docs Changes: in API/STYLE.md
Release Notes: N/A (v3alpha is not in use yet)
Fixes#8120
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 1371f2ef46582a72b5b3971147bd87c534011731
In order to get file level move annotation, import has to be before options.
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 062c895f499382ae61dead16db2a7e78b9146525
Description:
Implement `allow_missing` (but not failed) mode for JWT requirement. In this mode, token is not required for JWT filter to pass. However, if a token is presented, it must be valid.
This PR also change the `allow_missing_or_failed` (and the new `allow_missing`) to consider the provider within the container OR-list, instead of using the global one that have all providers. As a result, each `allow_xxx` will examine the interested tokens list independently. This correct the behavior when the `allow_xxx` is used multiple times, e.g in different ORs of an AND-of-OR requirements.
Risk Level: Medium
The PR changes the existing behavior of `allow_missing_or_failed`
Testing:
Unit tests.
Docs Changes: Added
Release Notes: Added
Signed-off-by: Diem Vu <diemvu@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 74436a6303825e0a6873222efff591ea1001cf87
Setting update_frequency to 0 causes a segfault. Prevent invalid values via validation.
Risk Level: low
Testing: added unit test
Doc Changes: updated
Release Notes: n/a
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3256d60fcb9710f0ffda856e72126fd957796409
The max_request_bytes field is assumed to have a value set that is
greater than zero. The code ASSERTs this and does unpleasent things
if not set. This corrects that built-in assumption. Note that this
field could be a primitive integer with a constraint, but it doesn't
seem worth that churn to fix.
Fixes https://github.com/envoyproxy/envoy/issues/7650
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ a3b15fccf1c4c8318af9493aa263abe07089bfd5
data-plane-api(CircleCI)