Due to a seg fault issue with the gogo protobuf library
[https://github.com/gogo/protobuf/issues/568], non nullable repeated
fields in a proto will cause proto.Merge(dst, src) to panic.
The nullable field setting was first added by @kyessenov when he was
re-organizing the protos. Unfortunately, people have been copy pasting it
across several areas in the Envoy proto. To keep the impact radius to a minimum,
I have updated only the fields that are currently causing the segfault
(in go-control-plane) for us.
Its also partly against proto principles. You should be able to determine if
a field is set or not. This non-nullable setting in gogo will insist on initializing
the field to default values.
Risk Level: to go control plane users
Signed-off-by: Shriram Rajagopalan <rshriram@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ b22d2b5cf09f779962cfedaaab24969f384cbc48
* grpc-json: add support for ignoring unknown query parameters
Current behavior is not to transcode a request that contains a query parameter
that cannot be mapped. In cases where there is a specific set of parameters to
ignore one can use ignored_query_parameters. If there is a proxy or client
adding query parameters that one cannot control this won't work and the
transcoder becomes useless. ignore_unknown_query_parameters solves this problem.
Risk Level: low to medium
Testing: Added a unit test for the transcoder.
Tested manually, locally.
Docs Changes:
Added field description in api/envoy/config/filter/http/transcoder/v2/transcoder.proto
Release Notes:
Signed-off-by: Neri Marschik <codesuki@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6af53be976c79a2b51a3f55825b722b58686c8a0
Signed-off-by: Emil Mikulic <g-easy@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ ea3ebca3b6d84a8b29c35ca03fa3666a0f4951c9
All http filters have build rules to generate cc protobufs, but not go protobufs. Added build rules (to a few filters) to generate go protobuf files. Emulates the rules in the health_check http filter.
Risk Level: Low
Testing: These rules were copied to google3 and tested internally. Unfortunately, I am having a bit of trouble with bazel build directly on these targets ("Package is considered deleted due to --deleted_packages"). Please let me know if there is a better way to test this change.
Signed-off-by: Teju Nareddy <nareddyt@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 23d82b9d14a6cf9f49ebcd3ae584fe3079f597d1
Description:
Before this change, Envoy would silently ignore the `x-envoy-*` header if a
client specifies an invalid value for this header (e.g. `x-envoy-max-retries: 3.0`).
Introduce a `strict_check_headers` config option for `envoy.router` that adds
optional support to reject requests with invalid values for the following headers:
- x-envoy-upstream-rq-timeout-ms
- x-envoy-upstream-rq-per-try-timeout-ms
- x-envoy-max-retries
- x-envoy-retry-on
- x-envoy-retry-grpc-on
On rejection, Envoy responds with HTTP status 400 and sets a new response flag
`IH` to indicate the reason was due to an invalid header.
Risk Level: Low/medium
Testing: unit tests
- unit test: `FilterUtility::StrictHeaderChecker`
- test that router rejects request with HTTP status 400 + setting the `IH` response flag
- test that config validation rejects unsupported values
- manual end-to-end test `client -> envoy -> upstream server` to verify that
Envoy returns a 400 and sets the response flag in the logs
Docs Changes:
- add inline docs to `router.proto` for `strict_check_headers`
- add inline docs to `accesslog.proto` for `IH` response flag
Release Notes: updated for router and accesslog
Fixes#6482
Signed-off-by: Xiao Yu <xyu@stripe.com>
Mirrored from https://github.com/envoyproxy/envoy @ ecd03a4eed07e1cfea9e9844e519b7fffada437a
Since this API is still experimental, tweaking to match best proto
practices.
Risk level: Low
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1faaed85740a97533484db3232796aef7973677f
This allows using Envoy as a generic HTTP proxy without any
prior configuration of DNS targets. See the included documentation
for more information.
Part of https://github.com/envoyproxy/envoy/issues/1606
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 79e53f21c680b4a02695b1761e7d91868c3481d4
Without a distinction between the root and subdir, we can't watch for
symlink swaps that cover multiple layers.
Risk level: Low
Testing: additional test expects added.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 49b5a915324e44b9445e3fc5434e0deffaf3f94f
Add edge_accept_request_id property for the envoy.http_connection_manager filter. Field added to resolve#6050 and also maintain backward compatibility
Risk: Low - small feature disabled by default and maintaining backward compatibility
Testing: Added 2 additional integration tests in test/common/http/conn_manager_utility_test.c to validate behaviour for:
1. edge request - activated edge_accept_request_id set to true but no x-request-id header sent - expected to generate a new one
2. edge request - activated edge_accept_request_id set to true and sent x-request-id header sent - expected to keep the old one.
3. all previous tests regarding edge requests resetting the x-request-id should still pass
Fixes#6050
Signed-off-by: trifan <trifan@adobe.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0243ded4b29be7c7d95316ca99eae2e3c517e1a4
Description: This adds support for forwarding peer cert chains via the XFCC header.
Risk Level: Low
Testing: Updated existing tests
Docs Changes: Updated XFCC doc
Release Notes: Added a note about the feature
Fixes#6135
Also see #6230
Signed-off-by: Venil Noronha <veniln@vmware.com>
Mirrored from https://github.com/envoyproxy/envoy @ 15abaec72b0374e29490e8e074751e6246980e87
This PR also fully deprecates the tcp_proxy v1 configuration.
This will be deleted following the standard deprecation cycle.
All new uses should use filter chain matching.
Fixes https://github.com/envoyproxy/envoy/issues/4457
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 866d0438d12ce9d39afb35ba200b0107bf3d6de3
This PR provides the TDS API config. The implementation and docs will be
added in a followup, the idea is to unblock some projects that depend on
the details here.
Risk level: Low
Testing: @envoy_api build
Part of #6708
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ad2cacc4215477526dc61f838db8a7ddf55f4cc6
To support TDS and to provide operator flexibility in how it relates to
existing runtime layering, this PR introduces support for explicit
control over layering. This eliminates the distinguished role of
subdirectory and override_subdirectory, for example, in favor of
arbitrary disk overlay layers.
This PR deprecates the existing runtime configuration in favor of the
new layered variant.
As a bonus, the PR fixes some of the runtime stats and related docs.
Risk level: Low
Testing: various unit tests (including server_test) additions.
Part of #6708.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4dafba65baaf9769723f895761268eed31af629b
Add an http filter to extract the original source on a per-http-request basis
Signed-off-by: Kyle Larose <kyle@agilicus.com>
Mirrored from https://github.com/envoyproxy/envoy @ 712a72a718969ef37eb05a57a7e11c94d5fe6253
As a first step towards TDS, add support for proto/JSON representations of the runtime virtual file
system and plumb this into bootstrap.
"numerator" and "denominator" are now reserved keywords and can't be used in runtime keys; this
simplifies parsing significantly. It is not expected that these are widely used, due to the
difficulty of ensuring atomicity if representing fractions, but this is technically a runtime API
breaking change.
Risk level: Medium (due to the reserved word changes).
Testing: Unit and server tests added.
Part of #6708
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ eb699ab2d53aadf2c5a26ed02fcc1e7de1df7d8a
Protos to statically and dynamically (via the Scoped Route Discovery Service) configure scoped
routing logic in Envoy.
Signed-off-by: Andres Guedez <aguedez@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2778c3c0c1e1f18a1c7864b4e7707e9d0ca2571e
Signed-off-by: Brian Rectanus <brectanus@signalsciences.com>
Mirrored from https://github.com/envoyproxy/envoy @ 77d267eef63edc215f93d140f61bfc711b59a31b
Reintroduce dispatcher stats previously reverted in #6649. Dispatcher stats are now gated on a new bootstrap config parameter, enable_dispatcher_stats, and disabled by default.
Risk Level: Low
Testing: Manually verified that config is respected (see #6582, this still requires integration tests).
Docs Changes: Included a note about how statsd doesn't play well with these high-volume histograms.
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 481a127f5ade32e5590b4e8b8271576e44643082
Change the behavior of the delayed_close_timeout such that it won't trigger unless there
has been at least a delayed_close_timeout period of inactivity after the last write event on
the socket pending to be closed.
This mitigates a race where a slow client and/or low timeout value would cause the socket
to be closed while data was actively being written to the socket. Note that this change does
not eliminate this race since a slow client could still be considered idle by the updated timeout
logic, but this should be very rare when useful values (i.e., >1s to avoid the race condition on
close that this timer addresses) are configured.
Risk Level: Medium
Testing: New unit tests added
Docs Changes: Updated version history and HttpConnectionManager proto doc
Fixes#6392
Signed-off-by: Andres Guedez <aguedez@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ cdaeb1344e4136d8c9ac33507005159c93087a49
Making the following deprecated fields fatal-by-default
UNSUPPORTED_REST_LEGACY from config_source.proto
use_alpha from ext_authz.proto
enabled from route.proto
type from fault.proto
runtime_key from route.proto
Risk Level: High (first time using this process - it will likely cause problems for someone)
Testing: tests pass.
Docs Changes: n/a
Release Notes: no
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 19894aca58f21f73dfbdb939ce8597c58de8a574
Read a string value from stream_info.FilterState, and use it to look up a JwtRequirement map in the filter config.
This is the PR to implement #6399
Risk Level: Low
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ abd625a6a77f4831a359416489691f0a81af694c
Description: modifies jwt_authn filter's ExtractorImpl extract method to use the from_headers's value_prefix tag more precisely, allowing syntax like "tag=<JWT>,other=xxx" rather than simply taking the remainder of the string as the JWT candidate.
See Issue #6355 for full description. Should be backwards-compatible with existing uses of jwt_authn.
Risk Level: Medium (scope: affects JWT authentication)
Testing: Unit testing was added to test/.../jwt_authn/extractor_test.cc. Since Extractor itself does not validate the JWT, only the parsing is tested.
Docs Changes: see "Further header options" section added to api/envoy/config/filter/http/jwt_authn/v2alpha/README.md
Release Notes:
Adds enhancement per Issue #6355, so that deployments can use a wider variety of HTTP header syntaxes to pass JWTs and have them authenticated by the jwt_authn filter. Backwards-compatible with existing usage.
JWT authentication with the jwt_authn HTTP filter now permits header syntax like the following:
Authorization: Bespoke jwt=eyJhbGciOiJS...ZFnFIw,extra=7,realm=123
Signed-off-by: Larry West <Larry_West@intuit.com>
Mirrored from https://github.com/envoyproxy/envoy @ 03cf28658399a7e411e49f9718782c919578d099
- Redis requests are now redirected to a new upstream connection
upon receipt of an MOVED or ASK error response. If the request
cannot be redirected, then the error is passed downstream unmodified.
The redirection IP (IPv4 or IPv6) address and TCP port specified
in the Redis server error does not need to reference a known host of
the cluster associated with the redis_proxy filter.
- added an enable_redirection boolean to the redis proxy connection
pool settings to control whether or not server redirection errors are
honored or passed downstream unchanged.
- RespValue copy constructor, copy assignment, and equality testing
methods for easier manipulation of RespValues.
- added cluster statistics, upstream_internal_redirect_succeeded_total
and upstream_internal_redirect_failed_total in ClientImpl::onRespValue()
callback
- extended unit tests for Redis connection pool, client, command
splitter, and RespValue copying and equallity testing.
- new basic integration test for redis_proxy: simple request
and response, and invalid request testing (enable_redirection
enabled).
Signed-off-by: Mitch Sukalski <mitch.sukalski@workday.com>
Mirrored from https://github.com/envoyproxy/envoy @ 378d59b43e71e07c36c9ef60b0ee7318ca7f510f
Provide the HTTP path normalization per RFC 3986 (sans case normalization). This addresses CVE-2019-9901.
The config HttpConnectionManager.normalize_path needs to be set for each HCM configuration to enable (default is off). There is also a runtime optione http_connection_manager.normalize_path
to change this default when not set in HCM.
Risk level: Low
Testing: New unit and integration tests added.
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7ed6d2187df94c4cb96f7dccb8643bf764af2ccb
This PR adds support to `ext_authz` filter for buffering the request data. This is useful when the authorization server needs to check the request body, e.g. HMAC validation.
Fixes#5676
*Risk Level*: low
*Testing*: unit
*Docs Changes*: yes
*Release Notes*: yes
Signed-off-by: Gabriel <gsagula@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 075edf802b9ef94bdf26fddc9e775f8bb89df92d