This is a first step towards https://github.com/envoyproxy/envoy/issues/17920
A single proto (kafka mesh) has been swapped from using the udpa
file_status annotation to the xds file_status annotation to avoid a
large amount of churn and a forthcoming migration of many alpha/wip
protos to non alpha/wip. The rest will be audited and swapped in
future PRs. This single one was done to make sure the doc machinary
works properly.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ f0f17a3caa75106a9e28b99edc27dd09c1bed488
This allows for dynamic metadata when using an HTTP authorization service. Currently, it is only possible to set dynamic metadata using a gRPC authorization service.
Risk Level: low, new opt-in feature in an extension
Testing: unit tests
Docs Changes: proto definitions documented
Release Notes: ext_authz: added :ref:dynamic_metadata_from_headers <envoy_v3_api_field_extensions.filters.http.ext_authz.v3.AuthorizationResponse.dynamic_metadata_from_headers> to support emitting dynamic metadata from headers returned by an external authorization service via HTTP.
Signed-off-by: John Esmet <john.esmet@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 31f48ee7a3c32ed383b46c8940263af9dc9bdcd4
upstream: Make the Alt-Svc cache configuration required if HTTP/3 is enabled with AutoHttpConfig.
Risk Level: Low
Testing: Unit tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Ryan Hamilton <rch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 19102ffc814204d2d2f98747afa3af3a84a4024c
This patch adds header_to_metadata field to JwtProvider config to allow
setting the extracted header of a successfully verified JWT to dynamic
metadata.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
Mirrored from https://github.com/envoyproxy/envoy @ 25622ce26532ad42d93a383d48b6c86d9e28d3d2
Removal of params or cookies after authentication is not implemented as of today.
authenticator.cc calls the removeJwt(...) if forward is set to false (default)
and this leads to an assertion failures caused by NOT_IMPLEMENTED_GCOVR_EXCL_LINE.
Changed removeJwt(...) for JwtCookieLocation to be empty, added test coverage
and updated proto doc to call-out this caveat.
Signed-off-by: Shubham Patil <theshubhamp@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5591dbc0f6d663641241f1919dc6135668c1da75
http: Unhide the AlternateProtocolCache configuration
and move some docs from http3_upstream.md to connection_pooling.rst
Risk Level: N/A - Docs only
Testing: N/A - Docs only
Docs Changes: Unhide the AlternateProtocolCache configuration and move some docs from http3_upstream.md to connection_pooling.rst
Release Notes: Added
Platform Specific Features: N/A
Signed-off-by: Ryan Hamilton <rch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d7fdbbc567b5e3175240c1fa9827255275c53c36
Today "disabled" and the processing mode are the two things supported
because that is what is currently supported in ext_proc.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 01ea37b280d980c25bb9e2c8069d62e4aef37961
Field 2 in the `DnsFilterConfig` message was released in Envoy 1.18,
and repurposed in Envoy 1.19. Renumber the field, while leaving a
compatibility field so that control planes can gracefully migrate to a
subsequent 1.19 release.
This fixes#17921.
Signed-off-by: James Peach <jpeach@apache.org>
Mirrored from https://github.com/envoyproxy/envoy @ ff9704e502184c4415d38351795f0d5d11627fcd
Support extraction of JWT from Cookies in JWT Extension
Added "from_cookies" config directive to jwt_authn that enables JWT extraction from request cookies.
Risk Level: low
Testing: unit tests
Docs Changes: Updated `docs/root/configuration/http/http_filters/jwt_authn_filter.rst`
Release Notes: Updated `docs/root/version_history/current.rst`
Platform Specific Features: None
Fixes#17424
Signed-off-by: Shubham Patil <theshubhamp@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 143083c3c3e78c9252b644648ef5be5cf9158419
`context_extenstions` map has the potential to contain secrets which need to be redacted from config dumps.
Risk Level: Low
Signed-off-by: Paul Gallagher <pgal@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5d9b58b4342448031f1343b670613a88c05da8b9
Stop generating v4alpha protos as it won't land in foreseeable future.
This fixes go-control-plane sync because of it fails to generate contrib API correctly.
Risk Level: Medium
Testing: CI
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ e453c6c613206da749e3ff645e2d92f534535f3e
Add a configuration option to use the value of an upstream-supplied
response header as the content length to allow streaming responses.
Risk Level: Low
Testing: Integration test for happy path and unit tests
Docs Changes: Inline documentation on new proto field
Release Notes: One line mention in version history doc
Platform Specific Features: N/A
Fixes#12957
Signed-off-by: Garrett Bourg <bourg@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ a63ab5436579b171bc85da8f3aa77a0c701d7f73
Mixing extensions with previously existing knobs leads to undefined behavior,
so this removes the deprecation around xff_num_trusted_hops and ensures that
it's not mixed with extensions.
Note that a unit test already exists for the original bug report, where
use_remote_address is used with xff_num_trusted_hops > 0. However it uses
the XFF extension instead of the old knob. Given this is now forbidden,
there's no need for additional tests wrt that config combination.
Fixes#17554.
Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ 57c172f8c3595b5f1e4b9ec9d56b7c8d7ec19c90
This is the last PR in the series dedicated to adding mirroring support.
It adds:
* the ShadowWriter which is used by the Router filter to mirror requests
* a ShadowRouter which is a RequestOwner that reuses the existing UpstreamRequest
There's still room for more code sharing and better interfaces, but that
can happen in future iterations.
Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7a93615ec1077bbb3b20ada1fc8a440751da1c9f
In order to unblock a dependency between route_components.proto and the matcher tree, move the alpha Matcher to
its own package. To provide an upgrade path for users using this, we'll keep the old copy around for a single deprecation
cycle.
Risk Level: Low
Testing: n/a
Docs Changes: n/a
Release Notes: Deprecation note
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 40ed33327c23a9e4e88aec448694eb1d03098efd
This PR addresses several issues:
1. MetadataFormatter base class takes a pointer to a function to access specific type of metadata. All other methods operating on internals of metadata structure are moved to base class. This simplified adding new types of metadata.
2. new type of access_log METADATA tag is introduced to handle all types of metadata. It is implemented as formatter extension. It handles existing tags DYNAMIC_METADATA and CLUSTER_METADATA, so two ways of accessing dynamic and cluster metadata are allowed now. Maybe we should obsolete DYNAMIC_METADATA and CLUSTER_METADATA in the future?
3. Adds handler for ROUTE metadata. See issue #3006.
Follow up to #16121
Risk Level: Low
Testing: Unit tests.
Docs Changes: Yes.
Release Notes: Yes.
Platform Specific Features: No
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 43b597e719230c8266998394301c5d0b3c862688
Implement the final unimplemented processing mode, which sends the
body in a single chunk if the entire body can be processed without
exceeding the buffer limit, or sends a chunk containing only the
part of the body that fits within the limit otherwise.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b6e72028c4be08e3e9926af970c10566d40d2841
When these fields were originally added, we didn't fully understand how the `CertificateValidationContext` configuration worked. A `CertificateProvider` cannot provide a full `CertificateValidationContext` proto; it provides only the CA certs (i.e., the `trusted_ca` field within the `CertificateValidationContext` proto). So this PR makes the following changes:
- Duplicates the `CertificateProvider` and `CertificateProviderInstance` messages from `CommonTlsContext` as `CertificateProviderPlugin` and `CertificateProviderPluginInstance` outside of `CommonTlsContext` (in common.proto instead of tls.proto). (Note that this also paves the way for reusing these messages for SPIFFE validation in the future.)
- Adds new `CertificateProviderPlugin` and `CertificateProviderPluginInstance` fields to `CertificateValidationContext`, as an alternative to the existing `trusted_ca` field. (Added annotations to make this a `oneof` in the future.)
- In `CommonTlsContext`, I have deprecated the `validation_context_certificate_provider` and `validation_context_certificate_provider_instance` fields both in the `validation_context_type` oneof and in `CombinedValidationContext`.
- In `CommonTlsContext`, I have replaced the `tls_certificate_certificate_provider` and `tls_certificate_certificate_provider_instance` fields with new fields that use the new messages outside of `CommonTlsContext`.
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 @ b29d6543e7568a8a3e772c7909a1daa182acc670
Implement this mode, which allows an external processor to receive the body one chunk at a time and examine or modify the body while it is being processed.
Risk Level: Medium. The mode is only engaged if used. However an external processor must be coded carefully, particularly if it expects to stream both request and response bodies simultaneously, since each will proceed in its own ordering.
Testing: New unit and integration tests.
Docs Changes: Updated proto docs to reflect that the mode is now supported.
Release Notes: External processing servers may now use the STREAMED processing mode. In this mode, chunks of the body are forwarded to the external processing server when they arrive. Depending on how the upstream system is implemented, request body chunks may be delivered before or after the response headers, and request and response body chunks may be interleaved if the upstream system delivers them that way. An external processor should be carefully coded so that it does not assume that a particular ordering will be implemented.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 271e67488b57bb600a1352c35aa9a7b8f1158441
#17110 the EnvoyMobileHttpConnectionManager but it turns out it's instantiated either as a standard network filter (needs a name) or as an API listener (which only accepted HttpConnectionManager)
Fixing both issues.
Risk Level: low
Testing: unit tests
Docs Changes: n/a
Release Notes: n/a
Part of envoyproxy/envoy-mobile#1540
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 463eda2f3895fbb24c1fcd085a15d00d12a94079
Risk Level: low (config guarded code)
Testing: new unit tests
Docs Changes: n/a
Release Notes: intentionally not added
Platform Specific Features: n/a
Part of envoyproxy/envoy-mobile#1540
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 8589ca86a4e937a57206b9be85d7faa9e8f0ca3d
Adding a core.v3.TypedExtensionConfig typed_dns_resolver_config for DNS resolver
in API definition. This configuration is to support DNS resolution as a first
class Envoy extension. This API change is the first step for that task.
This configuration is to replace above dns_resolution_config.
By default envoy supports c-ares DNS or apple DNS resolvers. This extension can be used
to configure other DNS resolver types.
This configuration is optional. In case it is missing, the default behavior is in place,
which means Envoy will either use c-ares DNS library or apple DNS library based on
the compiling flag. When this configuration is in place, Envoy will use the configured
DNS resolver carried in the extension typed_config field.
In case both typed_dns_resolver_config and dns_resolution_config are configured,
typed_dns_resolver_config take precedence.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b65b397652e5a627a9f3b0adcfe840d80dd57c03
Commit Message: jwt_authn: RemoteJwks to support RetryPolicy config #16319 ( only for background fetches failing )
Additional Description: following up on comments and code pruned from background jwks refresh mechanism from #16912
Risk Level: Low, default number of retries set to zero. truncated exponential backoff requires explicit configuration.
Testing: Only mock-based unit tests so far. Haven't been able to get it ( or the background jwks fetch option, for that matter ) built in [esp-v2](https://github.com/GoogleCloudPlatform/espv-2) so far.
Docs Changes:
Release Notes:
Platform Specific Features:
Fixes#16319
Signed-off-by: Anthony Lichnewsky <alichnewsky@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ b62dae29a5dd06b7f689899b26974d9567a98f0e
Input matcher that checks that an IP{v4,v6} belongs to a list of CIDR ranges
Signed-off-by: Adrien Guinet <adrien@reblaze.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6cd6a0cab68c757c785e62e0d73d881f57c97839
Commit Message: this PR adds the ability to prefetch hostnames to resolve during cache construction.
Additional Description: This feature can be used as a performance improvement for setups that use dns cache, but know a priori some of the hostnames that will be used.
Risk Level: low -- adds a feature that is off by default.
Testing: new tests
Docs Changes: added documentation in the API
Release Notes: inline
Signed-off-by: Jose Nino <jnino@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7b492bdff96649aee29017fcaabaf37a39407d8a
data-plane-api(Azure Pipelines)