Add functionality to configure kill header in KillRequest proto. If configured in the proto, it will override the default kill header.
Risk Level: Low, new feature.
Testing: Unit/integration tests.
Docs Changes: Added
Release Notes: Added
Issue: #13978
Signed-off-by: qqustc@gmail.com <qqin@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1d44c27ff7d4ebdfbfd9a6acbcecf9631b107e30
As per discussion summarized in
#13555 (comment), we will not use structured
xdstp:// names/locators in the API initially. Instead, we will re-use existing string fields for
names and special case any name with a xdstp: prefix. We leave open the option of introducing
structured representation, in particular for efficiency wins, at a later point.
Risk level: Low (not in use yet)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d1ded6b381ca92cbacb2e0683adf997239b12272
This introduces a new filter called the "external processing filter." It is intended to allow an external service to be able to operate as if it were part of the filter chain using a gRPC stream. It is intended to support a variety of use cases in which processing of HTTP requests and responses by an external service is desired.
A document that describes the filter can be found here:
https://docs.google.com/document/d/1IZqm5IUnG9gc2VqwGaN5C2TZAD9_QbsY9Vvy5vr9Zmw/edit#heading=h.3zlthggr9vvv
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 98d2f3b553b87c3e935f57ba15b4faf68b45d7f0
Replacing the http-protocol-specific fields in the cluster config with a new plugin
Risk Level: medium
Testing: updated tests to use the new config
Docs Changes: updated docs to use the new config
Release Notes: deprecation notes in the PR
Deprecated: all http-specific cluster config.
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 7554d61bccf136638bdfb383c10d049dc8bd3790
Add a KillRequest HTTP filter which can crash Envoy when receiving a Kill request. It will be used to fault inject kill request to Envoy and measure the blast radius.
Risk Level: Low, new feature.
Testing: Unit/integration tests.
Docs Changes: Added
Release Notes: Added
Issue: #13978
Signed-off-by: Qin Qin <qqin@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 237b29d6399953f22a47c6e4d19df74b4fbcee8d
Fixes#13082
Support skip decoding data after metadata in the thrift message.
In payload_passthrough mode, there are some issues:
Envoy cannot detect some errors and exceptions ( e.g. a reply that contains exceptions ). It's possible to improve this by peeking beginning of the payload.
payload_passthrough controls both request and response path. It can be split into two options if we want more fine-grained control.
FilterStatus passthroughData(Buffer::Instance& data, uint64_t bytes_to_passthrough) will not prohibit custom filters to modify buffer. Now it is assumed custom filters won't do that, otherwise behavior is undefined.
Risk Level: Medium
Testing:
unit test:
config
decoder
router
conn_manager
integration:
add an parameter payload_passthrough
manual:
send requests and verify responses
Signed-off-by: Tong Cai <caitong93@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2aee439cd15762cecda768a481b33bd88c999086
As per the decision to move the cncf/udpa repository to cncf/xds branding.
Also updated cncf/udpa hash and updated identifier handling (moved from repeated to a flat string).
Risk level: Low (the only breaking API changes affect not-implemented-hide fields).
Testing: New unit tests for path components.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8c4a3c77a7de016a118aacc4cea933951b85e589
#10526 allowed tracers to use CDS clusters. But zipkin proto doc still says bootstrap cluster is mandatory
Risk Level: Low
Testing: N/A
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6706d4413ad168d58267ee456428e56c9f0f78a5
When verifying Jwt clock constraint, it is recommend to use some clock skew. grpc is using 1 minute clock [skew](4645da201a/src/core/lib/security/credentials/jwt/jwt_verifier.cc (L388-L389)).
[jwt_verify_lib](https://github.com/google/jwt_verify_lib/pull/57) has been updated to add 1 minute clock skew.
In the old code, time constraint verification is done in jwt_authn filter, and jwt_verify_lib::verifyJwt() is doing time constraint verification again.
Change jwt_verify_lib to split the time constraint verification to Jwt class so it can be called separately. And call verify() without the time checking.
Risk Level: None
Testing: unit-test is done in jwt_verify_lib repo
Docs Changes: None
Release Notes: Added
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ cd684e76bda80e140ab90573815f1990ec6f2a6f
Some followup docs tweaks to #13721.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ dac6e58738d64b15ea26d1641906b68c16d55616
There are a few limitations in our existing support for symlink-based
key rotation:
We don't atomically resolve symlinks, so a single snapshot might have
inconsistent symlink resolutions for different watched files.
Watches are on parent directories, e.g. for /foo/bar/baz on /foo/bar,
which doesn't support common key rotation schemes were /foo/new/baz
is rotated via a mv -Tf /foo/new /foo/bar.
The solution is to provide a structured WatchedDirectory for Secrets to
opt into when monitoring DataSources. SDS will used WatchedDirectory
to setup the inotify watch instead of the DataSource path. On update, it will
read key/cert twice, verifying file content hash consistency.
Risk level: Low (opt-in feature)
Testing: Unit and integration tests added.
Fixes#13663Fixes#10979Fixes#13370
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 122257ef6ade0009feafc3c9142d480260fe069f
Add a new config field for an additional timeout that will cancel
streams that take too long to send headers, and implement it in the
HTTP Connection Manager.
Signed-off-by: Alex Konradi <akonradi@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e1c138b427ff9bcdf5ebcb2639cc2d22f98ac1a8
This patch adds a new tracer to support the SkyWalking tracing mechanism and format.
Risk Level: Low, a new extension.
Testing: Unit
Docs Changes: Added
Release Notes: Added
Signed-off-by: wbpcode <comems@msn.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7d0f89b1011503ecd22f28e347cf7f76cba73057
Adding support on per-route config with following goal: not to do RouteMatch twice. Currently the filter is using RouteMatch to match a request with a specific Jwt requirement. But RouteMatch is also performed at routing, so the RouteMatch is done twice.
If a Jwt requirement can be specified at the per-route config, one of RouteMatch can be eliminated.
1) Add a `requirement_map` to associate a requirement_name with a JwtRequirement in the filter config `JwtAuthentication`.
2) Add per-route-config as followings:
* a requirement_name to specify a JwtRequirement. or
* `disabled` flag to bypass Jwt verification if it is true.
Risk Level: None. Added a new feature, old features are not impacted.
Testing: Added unit-tests and integration tests.
Docs Changes: Yes
Release Notes: Added
Platform Specific Features: None
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ fe74d85d7d916eb975342e8298f2dc76279c1978
The comment in v3 version was missing the "If specified.." clause from the v2 version of that comment
Risk Level: low
Testing: Ran ./ci/run_envoy_docker.sh './ci/do_ci.sh fix_format'
Docs Changes: comment in a proto file changed
Signed-off-by: Sanjay Pujare <sanjaypujare@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f8e453fb43d5545730ddc90e10da541154d690b6
Use abort action as a default if killing is enabled and we're on a supported platform.
Risk Level: low
Testing: unit tests
Docs Changes: Included
Release Notes: Included
See PR #13208 for context as the reason it's part of core envoy and not an extension.
Signed-off-by: Kevin Baichoo <kbaichoo@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 415af040e09a1f6993c15ffc022793d39ecf5e8e
Signed-off-by: András Czigány <andras.czigany@strivacity.com>
Mirrored from https://github.com/envoyproxy/envoy @ dc3460c247538b8f81d49bd7984f46d142f20ba9
This is a follow up to 2c60632.
This forces all callers to think about multiple header values. There may be places that we want
to support multiple values, but none of them are security critical and this change should be
functionally equivalent to what exists today.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4d77fc802c3bc1c517e66c54e9c9507ed7ae8d9b
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 319a9a647f19036d831a75f68350c90e98bfc365
The java_outer_classname must not collide with a type defined within a proto
file in order to compile protos to Java. Additionally, this commit
introduces a format check to prevent this from happening again.
Risk Level: low
Testing: none
Docs Changes:none
Release Notes: none
Fixes#13368
Signed-off-by: Spencer Lewis <slewis@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 03f46bbdafae57a510d3a7fd8aa912efb9c71db3
This patch adds a per-route flag to bypass the request body buffering.
Fixes#13285
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 10e5a47fdc9c3120d24b4d3e5383d49ddeca344a
This patch allows setting an additional prefix for HTTP filter stats. This lets the emitted statistics from configured ext_authz HTTP filters in an HTTP filter chain can be distinguished from each other.
Risk Level: Low
Testing: Added a test on additional prefix.
Docs Changes: Added
Release Notes: Added
Fixes#12666
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 720348b822aed159dc4ec8243fffe95a8775a4cd
Add support for the letting the authorization service tell Envoy which auth related headers to remove once the authorization server is done with them, so that the upstream does not see them.
Signed-off-by: Martin Matusiak <numerodix@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 228c8ad78433c19b61eeaf9aad1c38ec1f2c75cc
Risk Level: LOW
Testing: Unit and format
Fixes#10535
Signed-off-by: Abhay Narayan Katare <abhay.katare@india.nec.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6321e5d95f7e435625d762ea82316b7a9f7071a4
The CdnLoopFilter implements an HTTP filter that detects and prevents
CDN loops using the RFC 8586 CDN-Loop header. The filter can be
configured with the CDN identifier to look for as well as the number
of times the CDN identifier can be seen before responding with an
error.
Signed-off-by: Justin Mazzola Paluska <justinmp@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c71ec2729cc3c0708223d303e0f24e3bf9a5d0eb
Add OCSP stapling support with configurable stapling policy. A pre-fetched OCSP response can be configured with its corresponding certificate via the new ocsp_staple field in the TlsCertificate message. The new ocsp_staple_policy field on DownstreamTlsContext determines whether an OCSP response is required and whether to continue using the TLS certificate for new connections once its OCSP response expires. The ocsp_staple_policy defaults to LENIENT_STAPLING, which allows the operator to omit ocsp_staples from the configuration and will only use OCSP responses that are present and valid. This should therefore not break any existing configurations.
Risk Level: Medium - touches some core functionality of certificate selection but does not alter any existing behavior
Testing: added
Docs Changes: Added OCSP Stapling subsection in the SSL section of the architecture overview.
Release Notes: Added
Runtime flags:
envoy.reloadable_features.check_ocsp_policy
envoy.reloadable_features.require_ocsp_response_for_must_staple_certs
Signed-off-by: Daniel Goldstein <danielgold95@gmail.com>
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ cdd3a837056dc6935c0d8e0fb693d4de89b998e9
This fixes the docs for REQ command operator usage example in LocalReplyConfig and SubstitutionFormatString protos. $REQ(:path)% is an invalid command operator, it should be %REQ(:path)%.
Risk Level: N/A
Testing: N/A
Docs Changes: This is a docs change.
Release Notes: N/A
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 130c7c4e271fe306ae4dd747daa5f09ff31aef79
Commit Message: Added max_connection_duration for tcp_proxy
Additional Description: Added max_connection_duration for downstream connection. After reaching max_connection_duration the connection will be closed.
Risk Level:
Testing:
Docs Changes:
Release Notes:
includes partial fix to #12077
Signed-off-by: Manish Kumar <manish.kumar1@india.nec.com>
Mirrored from https://github.com/envoyproxy/envoy @ 84f538f1ddcb5c16d98627df8b5e8c38f0f26720
Deprecated include_vh_rate_limits in favor of an enum setting vh_rate_limits.
Signed-off-by: Clara Andrew-Wani <candrewwani@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 433e88463fa52986b8071b2738bfdda5b8062b4d
Commit Message: CacheFilter: parses the allowed_vary_headers from the cache config.
Additional Description:
Parses the allowlist from the cache config proto; this allows users to define a set of rules to control which headers can be varied in the cache.
Risk Level: Low
Testing: Unit testing
Docs Changes: Updated cache proto's comments regarding allowed_vary_headers
Release Notes: N/A
Fixes#10131
Signed-off-by: Caio <caiomelo@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6a994d5afcd7fa038beac5113951afe6daaaf677
Additional Description: This PR necessitated decoupling SslHandshakerImpl from ContextConfig a bit. We now pass an int representing the index of the extended_info struct rather than the ContextConfig.
This PR moves SslHandshakerImpl to its own build target, moves SslHandshaker construction into the ContextConfig, and adds a HandshakerFactoryContext and HandshakerFactory for modifying the ContextConfig's behavior when constructing a Handshaker. This PR also adds a control (requireCertificates) to turn off the release asserts that a context must have certificates.
This PR builds off work in https://github.com/envoyproxy/envoy/pull/12571 and refines work done (and abandoned) in https://github.com/envoyproxy/envoy/pull/12075/. For more discussion please see the comments section of https://github.com/envoyproxy/envoy/pull/12075/.
Risk Level: Low. This PR does not modify existing handshaking behavior, it just adds an extension point for modifying it.
Testing: A representative alternative implementation was added under :handshaker_test.
Docs Changes: N/a
Release Notes: N/a
Signed-off-by: James Buckland <jbuckland@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7d6e7a4e559bdf0346687f7f404412e2412ea6fb
Simplified Profile Action to have a per-process limit rather than a per thread limit which simplifies disk-filling concerns.
We want to prevent the profiler from filling the disk, and using a per thread limit creates more complexity and profiles (i.e. for the "global" limit would be #threads * limit per thread vs limit per process. The former is harder to reason about.
Signed-off-by: Kevin Baichoo <kbaichoo@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ faab20c8477827643ae2e22b25b28fef631f0d89
This patch introduces hash based routing functionality.
It is very similar to tcp's one.
Previously, the udp proxy does not support hash based routing.
So, even if the lb_policy is set, load balancing algorithms will
select a host randomly.
This patch may very useful if some packets should be routed to same host
continuously.
Signed-off-by: DongRyeol Cha <dr83.cha@samsung.com>
Mirrored from https://github.com/envoyproxy/envoy @ a92c496754f04f624729937b9812c5fc4c44b371
data-plane-api(Azure Pipelines)