Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0c8942dd82e3991d5162c4c53ec5b2e5c1d71010
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
- Removed the JsonV1Serializer and added exception for HTTP_JSON_V1version in Serializer creation.
- Specified collector_endpoint_version in the test
- Removed the default value for endpoint_, it is redundant here because in the zipkin.proto, it has PGV rule [(validate.rules).string = {min_len: 1}], so we always need to provide the config for this field.
- Modified the ConstructBuffer test to create the buffer using ZipkinConfig::HTTP_JSON
Risk Level: LOW
Testing: CI
Signed-off-by: Tianyu Xia <tyxia@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ db74e313b3651588e59c671af45077714ac32cef
Update the 14 day API compatibility exception to make it clear that
whether a field has already been included in an Envoy release may
affect whether incompatible changes should be made.
This updates #17920.
Signed-off-by: James Peach <jpeach@apache.org>
Mirrored from https://github.com/envoyproxy/envoy @ 702cadcd8ba887744f5eb5541d6560ddef984976
`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
This PR is a continuation to #17515 - it adds a script that uses buf to check for breaking changes on proto files in the api folder. It does so by comparing the current api folder against the api folder at the git commit computed by tools/git/last_github_commit.sh - that should hopefully represent the most recent commit on main (if there is a better method to obtain the base branch commit, let me know!).
Adding the script also required re-organizing some of the breaking change detector logic from the previous pr: some levels of abstraction were added, and the detector now expects a git repository and ref as the input for initial state (rather than a proto file).
The script is invoked in do_ci.sh if bazel.api_compat is specified as the CI_TARGET.
This PR also bumps the buf bazel dependency to 0.53.0. If this is preferred to be in a separate PR, let me know and I would be happy to do so
Risk Level: low (hopefully) - the CI script will be invoked in a separate CI pipeline job that can be set to be optional on github. The azure pipeline has been added but needs to be set to optional by a CI maintainer
Testing: New scripts and logic were tested manually; also ran tests from the previous PR and they still pass. hoping to observe more output of this tool through reading CI logs of other PRs once this is merged (this PR should not affect the existing PR workflow - refer to Risk Level)
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: CI script uses a linux binary for buf so it cannot be run outside of docker on non-linux systems
Fixes#3368
Signed-off-by: Yaseen Alkhafaji <yaseena@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f30c289e456df11d549d7236c56f22da00500e9e
- Add cluster header to weighted cluster proto. This enables the ability of routing to the cluster specified in the request_header for weighted cluster (i.e. multiple upstreams) case. name and cluster_header will be oneof cluster_specifiter field in the next release. Currently, they can only be regular fields due to compatibility issue.
- Add the validation logic (PGV annotation + runtime check)
- Add 3 unit tests for invalid weighted cluster configs.
Note: I have implemented the core implementation and tested it with end-to-end
integration test/example locally. Those changes will be in a separate PR once this API change is approved.
Risk Level: Low
Testing: CI, added an integration test for implementation of this API locally
Signed-off-by: Tianyu Xia <tyxia@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ef70185f3ac241d09eabfe15c65b0d631134f74f
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
* config/router/tcp_proxy/options: v2 API, boosting and --boostrap-verison CLI removal.
This PR cleans up a bunch of v2 tech debt, including version conversion and API oracle
code:
* Remove all non-trivial field references to hidden_envoy_deprecated_*. These were primarily
in tcp_proxy and router.
* Remove boosting, hidden type annotation and the API type oracle. We are now only v3 for
both resource and transport API version.
* Remove --boostrap-version flag (all boostraps already must be v3).
Risk level: High (It's possible there were some runtime guarded or not dependencies on
boosting).
Testing: Validated test functional coverage when removing hidden_envoy_deprecated_* field tests.
Releasing notes: TODO
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d142c9d55ae9aab34e9924aa25f20bd27635e060
Follow-up to #17375 where it was agreed that protolock is not actively maintained enough to depend on. This PR "migrates" the tests from that PR to use buf instead, and also cleans some of the code per a few of the review comments. Still a few outstanding points:
- buf build on the envoy/api folder requires several protobuf dependencies such as udpa to be available to buf to consume. Suggested solution by buf is to point buf's config to necessary BSR modules that the buf team is hosting.
- These lines are commented out in this PR as I had some trouble automating it for the tests, and it is not necessary for the tests to pass
- May introduce issues if buf is not pointing to the same version of modules that bazel builds for envoy. May need to introduce some way to couple them, or (ideally) find a way to run the breaking change detector without building the dependencies
- Currently bazel is using a binary release of buf (for linux). Goal is to move to building it from source in the near future
- It may be in our interest to expand the list of API-breaking-change rules (buf provides an extensive list of rules we could adopt)
Risk Level: Low
Testing: Tests that evaluate buf against "allowed" and "breaking" protobuf API changes. Currently 4 tests are skipped - 3 of them are PGV-related (we need to communicate our desired PGV rules to the buf team so they may add them in the near future). The 4th is a test I had originally written to evaluate protolock but may not apply to buf ("forcing" a breaking change) - refer to comments
Docs Changes:
Release Notes:
Platform Specific Features: buf binary imported by bazel is linux-only. Hopefully the ["manual"] tags attribute prevents any issues for non-linux users
Signed-off-by: Yaseen Alkhafaji <yaseena@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c74cebb3cc7dfb26488f7cac8eb9258cf9a7588e
Enables `LOAD_BALANCING_POLICY_CONFIG` enum value in `LbPolicy` and supports typed load balancers specified in `load_balancing_policy`. Continues work done by Charlie Getzen <charliegetzenlc@gmail.com> in #15827.
Custom load balancers specified by `load_balancing_policy` are created as implementations of `ThreadAwareLoadBalancer`. Thread-local load balancers can be implemented as thread-aware load balancers that contain no logic at the thread-aware level, i.e. the purpose of the thread-aware LB is solely to contain the factory used to instantiate the thread-local LBs. (In the future it might be appropriate to provide a construct that abstracts away thread-aware aspects of `ThreadAwareLoadBalancer` for LBs that don't need to be thread-aware.)
A cluster that uses `LOAD_BALANCING_POLICY_CONFIG` may not also set a subset LB configuration. If the load balancer type makes use of subsetting, it should include a subset configuration in its own configuration message. Future work on load balancing extensions should include moving the subset LB to use load balancing extensions.
Similarly, a cluster that uses `LOAD_BALANCING_POLICY_CONFIG` may not set the `CommonLbConfig`, and it is not passed into load balancer creation (mostly owing to its dubious applicability as a top level configuration message to hierarchical load balancing policy). If the load balancer type makes use of the `CommonLbConfig`, it should include a `CommonLbConfig` in the configuration message for the load balancing policy.
Considerations for migration of existing load balancers:
- pieces of the `ThreadAwareLoadBalancerBase` implementation are specific to the built-in hashing load balancers and should be moved into a base class specifically for hashing load balancers. As it stands, custom load balancing policies are required to implement a `createLoadBalancer()` method even if the architecture of the LB policy does not require a hashing load balancer. I think we would also benefit from disentangling `ThreadAwareLoadBalancerBase` from `LoadBalancerBase`, as the former never actually does any host picking.
- as we convert existing thread-local load balancers to thread-aware load balancers, new local LBs will be re-created upon membership changes. We should provide a mechanism allowing load balancers to control whether this rebuild should occur, e.g. a callback that calls `create()` for thread-aware LBs by default, which can be overridden to do nothing for thread-local LBs.
Risk Level: low
Testing: brought up a cluster with a custom load balancer specified by `load_balancing_policy`; new unit tests included
Docs Changes: n/a
Release Notes: Enable load balancing policy extensions
Platform Specific Features: n/a
Fixes#5598
Signed-off-by: Eugene Chan <eugenechan@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e31bc1edec3bb80760a1442869cc442d123e9adc
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
use one destination port range rule to cover thousands of port rules in RBAC permissions, adding convenience for writing configuration and making matching quicker
Risk Level: Low
Testing: Unit
Docs Changes: N/A
Release Notes: Added
Platform Specific Features: N/A
Fixes#16039
Signed-off-by: Xie Zhihao <zhihao.xie@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0d2418e9f19d50197ed237dfe5497c715d3c99f0
Replace the confusing word with official defination
Signed-off-by: Le Yao <le.yao@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3a4baf64a5c300739b7ce47128c1e62fd2a38f33
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
data-plane-api(Azure Pipelines)