This extension simply allows to add user-defined dynamic metadata. This is intended to be used with matchers, so that the "result" of a matching process can imply specific metadata.
See issue #16266
Risk Level: Medium
Testing: Unit tests for the extension are added
Docs Changes: A small documentation for the extension is added in docs/root/configuration/http/http_filters
Signed-off-by: Adrien Guinet <adrien@reblaze.com>
Mirrored from https://github.com/envoyproxy/envoy @ cbe08bbe33005c1832964f7c9e657d6dbe105bbb
These changes clarify that as of v1.16 the default cipher suite is different for client and servers.
Risk Level: Low
Testing: N/A
Docs Changes: Yes
Release Notes: N/A
Platform Specific Features: N/A
Fixes#16469
Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c94e646e0280e4c521f8e613f1ae2a02b274dbbf
Marks the matching API more clearly as experimental and updates the composite filter security posture to reflect this.
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ b6039234e526eeccdf332a7eb041729aaa1bc286
Enable `is_optional` field for `HttpFilter`. The default value is `false`, it will keep the same behavior with the current implementation. The envoy will reject the unsupported HTTP filter, also will reject the unsupported HTTP filter in typed per filter config. When the value is `true`, the unsupported HTTP filter will be ignored by the envoy, also will be ignored by typed per filter config, with a warning log.
Risk Level: low
Testing: unit tests and integration tests are added
Docs Changes: API doc is added
Release Notes: added as new feature
Fixes#15770Fixes#15025
Signed-off-by: He Jie Xu <hejie.xu@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ ea4cadcd0e33da0c0e8272131866874b0ea377fb
grid: Plumb the AlternateProtocolCache down to the grid from the UpstreamClusterManager.
Create a new AlternateProtocolsCacheOptions proto message for configuring an AlternateProtocolCache, and add this message to AutoHttpConfig.
Create a new AlternateProtocolCacheManager class for fetching/creating a Cache based on the config.
Modify the AlternateProtocolCache to store state per thread. (Does not yet synchronize this state across threads)
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 @ 964de6c2a166bb7f66a9293a2e2e8cb6040dfbf2
This is a follow-up to:
#14432 (comment)
After that PR, it's no longer possible (unless you do a dynamic_cast)
to set the remote address from a filter. This is something that we
need to do because we have specialized logic for this (XFF doesn't
work for us).
So this adds an extension point which will allow us to push that logic
down to ConnectionManagerUtility::mutateRequestHeaders() where it
belongs.
Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ beac1ece7512e6e39b4f1c29490e247996a0f51c
canonical must include the hashed payload for most services. The prior
behavior of using UNSIGNED-PAYLOAD is an exception to the rule, which
select services like s3 support, since hashing the payload may be
impractical if the payload is very large.
A new filter option is introduced, so that the filter may be explicitly
configured to use the UNSIGNED-PAYLOAD string literal as specified
in the S3 signing docs:
https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.htmlfixes#13904
Additional Description:
The original implementation was seemingly very specific to S3 and was subsequently amended to extend the same niche singing behaviors for ES and Glacier. This changes the filter's default behavior to match the general SigV4 guidelines while providing a configuration option to enable the specialized UNSIGNED-PAYLOAD behavior.
https://docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
Risk Level: Medium?
Deployments using the filter will now buffer requests by default, which could result in 413 responses for requests with bodies exceeding the buffer limit. These users can mitigate buffering by enabling the `unsigned_payload` option.
Testing:
I tested locally with a filter config. I anticipate updating the automated tests based on feedback from maintainers.
Docs Changes: Added
Signed-off-by: Jonathan Stewmon <jstewmon@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 80e1ca899e3170c8f87dfd300c9c5dacc76d100b
This fixes the refs in protos and removes the sed operations for build
The benefits are:
- less indirection in proto refs
- (small) speedup of build
- simplify docs build
- simplify reuse of proto comments (eg generating jsonschemas)
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 45ec050f91407147ed53a999434b09ef77590177
This allows self-contained bootstrap without extra token files.
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ a5020ce885592e8e3a5d9bb644554a30c0f79a18
Add support for starttls on the client side. This is exactly the same
code as used for the server implementation, just reused.
Risk level: Low
Signed-off-by: Bryce Anderson <banderson@twitter.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9f2bb17be1fe970119e18dbe507dc2ddd31928e6
Config proto for Secure Session Agent (S2A) transport socket extension (#16110).
Signed-off-by: Tavish Vaidya <tavish@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ abe2f9b4af4b3c697ee8b3fda934aa2e181bc5ef
Port stripping the host for CONNECT requests for the duration of the filter chain (reinstating before sending upstream)
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 8c714008ed9d98c15ee18d645fdd59e18db2d9c2
Introduce the ability to add request headers to forwarded upstream requests when the local HTTP rate limit filter determines (through its configured ruleset) that a request should be rate limited, but is not hard enforcing the incoming traffic.
Additional Description:
This is useful when a backend service should take customized action when a particular traffic volume is reached, rather than forcing request shedding by the proxy.
Risk Level: Low, adding a new feature
Testing: Modified unit tests
Docs Changes: Updated associated doc
Signed-off-by: William Fu <wfu@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ ce1cb0ed18b6a6b8f6ddecb820424cec63b1cc31
Existing trailers will be sent to the processing
server if the processing mode is set to enable them. If the
processing mode is set to sent trailers, but there are no trailers
present, then empty trailers will be sent to the server for
modification.
However, trailers may only be added in the end of the data callback
in Envoy, which may come in before a previous gRPC reply returns.
Filters that need to be able to consistently add trailers where none
existed should enable trailer processing in the Envoy filter
configuration instead of relying on being able to turn it on
dynamically.
Risk Level: Low. Trailers only enabled if a service called by the filter
is configured to ask for them.
Testing: New integration and unit tests added.
Docs Changes: API docs updated in .proto files.
Release Notes:
When the processing mode is changed to SEND
for request or response trailers, a corresponding message will be
sent to the server, which can respond with trailer mutations as desired.
In addition, if trailer processing is enabled in the filter
configuration, then trailer messages will be sent to the server
even if trailers are not present. This makes it possible for the server
to add trailers where none exist.
Finally, at the moment Envoy only implements trailers for the HTTP/2
protocol. Nothing will happen if trailer processing is enabled and
Envoy is using HTTP/1 until Envoy implements trailers for HTTP/1.
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 29eb17096e50fc9385edbf260c03da7adc4ca24c
Commit Message:
Raise max configurable max_request_headers_kb limit to 8192 KiB (8MiB) from 96 KiB in http connection manager protobuf.
Additional Description:
Added/Updated relevant unit tests and integration tests. This change will allow increasing max_request_headers_kb to 8MiB from http connection manager's configuration. The change is mainly updating the limit in a validation check in the protobuf. Also, the old (merged) PR #5859 is read, no nghttp2 library-related issues are observed on raising the max_request_headers_kb beyond 96 KiB.
Risk Level: Low
Testing: Unit, Integration, Manual
Docs Changes: Inline in proto file.
Signed-off-by: Anirudha Singh <ps.anirudha@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ d20dbc4be73d2e185ecc3a8159ca95150e204aaa
Adds a new filter that makes use of the new matching API to allow specifying a filter configuration to use for specific match
results. Once a configuration is selected, the desired filter is created and all callbacks delegated to the specific filter.
Risk Level: Low, new filter
Testing: IT + UT
Docs Changes: Inline proto comments
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ d31ba23d494c310973ceaf1e053393697821e4d3
Commit Message: allow HCM to config Http3Options and use it with other HCM configs, i.e. max_request_headers_kb and headers_with_underscores_action, to setup QuicHttpServerConnectionImpl. And support these configurations in QUIC. Currently the only Http3Options configuration is override_stream_error_on_invalid_http_message.
Additional Description: added Http3 codec stats. Pass it along with Http3Options and other HCM configs.
Risk Level: low
Testing: enable related tests in quic_protocol_integration_test
Docs Changes: updated docs/root/configuration/http/http_conn_man/response_code_details.rst
Part of #12930#2557
Signed-off-by: Dan Zhang <danzh@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c93d486c2d303dbf2cc9f88717de0bfd66e1afdb
Adds some basic structure for validating match tree constructions, only
with support for validating the data input. Updates the HTTP filter
factory to be able to specify data input requirements and wires it up.
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ afb751344c93f6eb02ea1bd1630a282c55c7aef2
Fixes a few issues with the generated Go protobuf code:
a) the OT protos are not copied over, which means that their importpath
needs to reference a path where it can pull the protos down from. The
"logs" importpath was nonsensical and couldn't be resolved
b) Bunching several proto packages into one target did not work well
with the go package system. This splits the common protos out into its
own target so that it can reference a different importpath than the
other logs protos
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8037370ce45d8c10654114b2b46e27377525c156
Adds support for a "generic input" extension point that allows specifying inputs that are not dependent on protocol data.
Adds an environment variable generic input that allows matching on the value of an environment variable.
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 758a9a90c15331fbfd093f23170454c5a2fbf903
Adding a deprecated API version annotation to deprecated fields and enum values in proto files.
This is part of the work on adding minor/patch versioning work.
Risk Level: Low (adding annotation to existing protos).
Testing: Added and modified tests for the tooling (in tools/testdata).
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5a8bfa20dc3c85ecb61826d122696ecaa75dffa0
This adds the foundations of support for glob collections in CDS/SRDS
(in addition to LDS from #14311) and singleton collections in RDS/EDS.
xdstp:// URLs are not normalized across the internal resource graph yet,
so this is only safe to use for sorted context parameters (followup PRs
planned on this).
Part of #11264.
Risk level: Low (opt-in)
Testing: ADS/SRDS integration tests added, various unit tests in
//test/common/config/...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ fbb7f9ae4171b89a5b622587fec0564820e400ce
some of the category annotations are not in the correct place - this is one of them
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 5b875969d4571fc5bda77d6340d100142ed98797
This PR adds an OTLP logger to Envoy, which allows users to flexibly configure their log structure (according to OpenTelemetry protos).
The API users the common gRPC configuration, used in ALS, for gRPC settings. The flexible OT fields (body, attributes) are completely configurable and are filled with request/response information based on Envoy access log formatting.
There are still a couple of TODOs -
The 'filter_state_objects_to_log' from the common gRPC config isn't added to the log
Resource attributes are not configurable, and only Envoy node info is added.
Note: this extension was added as v3alpha API.
Risk Level: Low - a new extension, so unlikely to break any existing setups (marked as v3alpha API).
Testing: Unit tests.
Docs Changes:
Release Notes: access log: added a new :ref:OpenTelemetry access logger <envoy_v3_api_msg_extensions.access_loggers.open_telemetry.v3alpha.OpenTelemetryAccessLogConfig> extension, allowing a flexible log structure with native Envoy access log formatting.
Signed-off-by: Itamar Kaminski <itamark@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4f52f9ef554e1522e763c0eaf6ef6833aab283e5
Since ext_proc is a request/response protocol on a gRPC stream, a server may fail to respond in a timely way. The "message_timeout" field in the configuration controls how long the proxy will wait for an external processing server to respond to an individual message before giving up and returning an error (or not depending on configuration).
Signed-off-by: Gregory Brail <gregbrail@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5204a63a49ff09fcd57f189c2addf7f36ffac87c
This is a fast follow from https://github.com/envoyproxy/envoy/pull/15388.
I realized that I made a mistake in not using a common configuration
message. There will be more configuration options such as GRO, etc. that
will be configured similarly in multiple places. I'm correcting this
mistake now since the other change just landed within the last couple of
days.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ bd05ab7b74c2ee288aea9772a03d521cd761bd59
Release notes linked to explanatory docs not API changes, so didn't catch it was still hidden.
h/t @ggreenway for noticing.
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 0acf24ed2580c787227dc7c31f394ac583a598ae
1) Add configuration for max packet size to UDP listeners
2) Add configuration for max packet size to UDP proxy filter
3) Fix crashing issue when a GRO receive is truncated. This
was fixed in the open because GRO recieve does not support
IP fragmentation, thus the previous size of 24000 bytes was
large enough to receive a jumbo frame size datagram. The issue
is now exposed by allowing packet size to be configured larger.
4) Reorganize code and some config around UDP listeners to streamline
the logic when the listener is a UDP listener. Also moved the UDP
batch writer configuration to a better place since it's still
effectively alpha and was marked not implemented.
Fixes https://github.com/envoyproxy/envoy/issues/15327
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 73eec645a39343eec33b5d61bf492ba49c397cfe
This introduces a new matcher that allows matching on an input value by
computing a hash value and matching if the value % (configured value) is
greater than a configured threshold. This is useful in being able to
define match criteria that should match for a certain % of input values
in a way that is consistent between independent Envoy instances (e.g. it
does not rely on a random input).
Risk Level: Low, new extension
Testing: UTs
Docs Changes: Inline proto docs
Release Notes: n/a
Platform Specific Features: n/a
Fixes#14782
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7fe3d358f7e7e4d4c7282d50c498a7ab0e759a36
data-plane-api(Azure Pipelines)