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
Added a watchdog extension that triggers profiling.
Risk Level: Medium (new extension that is optional)
Testing: Unit tests
Docs Changes: Included (added a reference to the generated extension proto.rst)
Release Notes: Included
Fixes#11388
Signed-off-by: Kevin Baichoo <kbaichoo@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c88515fc0c8a291992732947671190b37949bbbd
This was written by Derek Argueta originally. Some more
work might be needed to make it more generic.
Risk Level: low, new filter
Testing: unit tests included
Docs Changes: filter docs added
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Co-authored-by: Derek Argueta <darguetap@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c6bfd7f9f52468d576781a9b1fe9ea5d3f9086c9
This is the 1st PR for #11832 that factors out the TAP filter matcher to prepare for reuse in other filters.
Signed-off-by: Yangmin Zhu <ymzhu@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 520389e677cdcd4a85df769deb40f6cdd2f4f6f8
Description: Upstream Wasm proto files from envoy-wasm.
Risk Level: Low
Testing: Unit tests in envoy-wasm, integration tests in istio/proxy.
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: John Plevyak <jplevyak@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 26eaa2e85cee69e5c32ab6bf4c5ae3d338fa462f
Commit Message: Add proxy proto transport socket
Additional Description: This is the part 1 PR described in #10682. It adds the transports socket / unit tests, a transport socket options struct for the proxy proto header, and does a refactor to make the listener filter use the common proxy proto constants (potentially want to move these now since the proxy proto config api type is not in extensions?)
Risk Level: Small
Testing: Unit
Docs Changes: None
Release Notes: None
Part Of: #1031
Signed-off-by: Weston Carlson <wez470@gmail.com>
Co-authored-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 8972b478e6c9f1e7342e3dbfb57b35317c0cc009
split out from #11327
There's a bit of transitive ugliness: declaring the extensions requires security posture, requires stub build files, requires codeowners before the code move, but it'll be pretty short lived.
Risk Level: Low (mostly only APIs)
Testing: n/a
Docs Changes: some of the new docs
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ e8dc25ecec277c0b94d02151de79353a9ba07b4e
This extension is used in production and we should treat it as such.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 86caf439d6cae2c8173b19fd4fdc95361565a72d
Commit Message: add generic decompressor filter
Risk Level: low - low as it is an extension, med - for users as this is a brand new filter.
Testing: unit tests, integration tests
Docs Changes: added docs
Release Notes: added release notes
Signed-off-by: Jose Nino <jnino@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 48a5b21d9483e7eddac79aeff7daac178d7b7462
Description: router: Create InternalRedirectPolicy to capture all internal redirect related options and extend it with pluggable predicates similar to retry plugins. The previous_routes and whitelisted_routes predicate allow creating a DAG of routes for internal redirects. Each node in the DAG is a route. whitelisted_routes defines the edges of each node. previous_routes serves as visited status keeper for each of the edge. This prevents infinite loop, while allowing loop to exist in the DAG.
Risk Level: Medium
Testing: Unit tests. Integration tests.
Docs Changes: Updated HCM architecture overview page. Added toctree for the predicates.
Release Notes: Updated version history.
Signed-off-by: pengg <pengg@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1ce010929d4d283fce977bc65558da71ffe6bf7c
creates decompressors as an extension point and moves the zlib based gzip decompressor.
Signed-off-by: Jose Nino <jnino@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 520e0c7050564ac7886129a87290e9e433470efd
Currently the generic HTTP compressor filter isn't exposed to users
even though it's used internally by `envoy.filters.http.gzip` and can be
used by external filter extensions.
Expose the compressor's config API to users. For example the filter
can be configured as follows:
...
filter_chains:
filters:
- name: envoy.http_connection_manager
config:
http_filters:
- name: envoy.filters.http.compressor
config:
disable_on_etag_header: true
content_length: 100
content_type:
- text/html
- application/json
compressor_library:
name: envoy.filters.http.compressor.gzip
config:
memory_level: 3
window_bits: 10
compression_level: best
compression_strategy: rle
...
Multiple compressor filters using different compressor libraries,
e.g. gzip and brotli, can be stacked in one filter chain.
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@linux.intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 49efb9841a58ebdc43a666f55c445911c8e4181c
This change adds DNS Request Parsing to the DNS filter. The filter will parse and decode DNS requests for A and AAAA records. Tests simply validate that the filter can consume queries.
Signed-off-by: Alvin Baptiste <alvinsb@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 54cd4d49e895befb8ecb10ebb14585cd8fc71ee7
Description:
The filter implements decoding postgres wire protocol and parses messages exchanged between postgres server and client. Based on the decoded messages the filter generates statistics (counters) indicating how many messages of a specific type were exchanged. #9107
Risk Level: Low: The filter is implemented as extension and the code is not executed unless inserted into filter chain.
Testing: Added unit and integration tests.
Docs Changes: Yes - added architecture overview chapter and configuration specific sections
Release Notes: Yes
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Co-authored-by: Dhi Aurrahman <dio@tetrate.io>
Co-authored-by: Fabrízio de Royes Mello <fabrizio@ongres.com>
Mirrored from https://github.com/envoyproxy/envoy @ f599ad7c05824a2cdbcde60ab2c035d264cd4247
This commit is this base structure and api definition
for the DNS filter. The code itself takes no action
on packets. Tests will be added later.
Signed-off-by: Alvin Baptiste <alvinsb@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ b3949eaf2080809b8a3a6cf720eba2cfdf864472
This filter transform HTTP requests to AWS Lambda invocations.
The filter supports pass-through only. Meaning, the request body
is passed to Lambda as is. Note: Lambda requires the request to be in
JSON format.
In a later iteration, we'll wrap the headers the body in a JSON string
before passing it to Lambda.
The filter requires the ARN of the Lambda function and supports
per-filter-config. When the per-filter configuration is used, the target
cluster must be tagged with specific metadata. This indicates to the
filter whether to process the request or to skip it.
Lambda supports two invocation modes:
- Synchronous (Request-Response)
- Asynchronous (Event)
This initial version of the filter supports the synchronous mode only.
In a later iteration I'll add support for the asynchronous (Event-based)
version.
Signed-off-by: Marco Magdy <mmagdy@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 807401004d500899e9aa4c78fce007cf83b538cd
This new alpha filter injects authentication headers for requests
directed at AWS services that require authentication.
Note:
Requests over plain HTTP aren't handled yet, since the message body
needs to be signed.
Fixes#9708
Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ ee2306673b79215641be02893cb4d8b2b256c466
Add Client Status Discovery Service (CSDS) API definition. This can be used by debug tools to obtain config information for specific clients from control plane.
Risk Level: Low
Testing: N/A
Signed-off-by: Fuqiang Gao <fuqianggao@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 10f756efa17e56c8d4d1033be7b4286410db4e01
Currently supported retry host predicates only allow omitting either previously tried or canary hosts. This enhancement is to add a new host predicate that looks at the endpoint metadata match and omits the host in case of a match with the host metadata. See #9531
Risk Level: Low
Testing: Unit testing
Docs Changes: Added new proto for omit_hosts
Signed-off-by: Prakhar Gautam <prakhag@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ e2fdf70f0fca0f9a9a66046fd80b280981b3f0ed
This PR introduces a parallel v3 API reference documentation tree to the
existing v2 one.
The docs/root/api-v3/ tree was copied from docs/root/api-v2 and the
necessary package path fixups were made manually. As a result, the tree
largely resembles the v2 docs. Long term this is likely to evolve to
reflect the shape of the new extensions tree.
The message type, field and enum anchors are sed'ed to be distinct and
self-consistent inside api-v3/.
There were a number of API proto changes that were made to obtain a
successful Sphinx build:
* References to deprecated fields were replaced by references to the replacement field.
* clang-format line wrapping in protoxform was removed, this breaks RST in some v3 protos.
* Some packages (type/metadata/v2, data/cluster/v2alpha) were force upgraded to v3, to deal with references to types that are distinct in v2/v3. This is OK as these packages probably make sense to bump for v3, in general we're going to have to think about how to do this more
cleanly, supporting dual v2/v3 references alongside each other.
* Some evil hacks for field renaming added to migrate.py for RouteAction.
There's also some additional machinery added to compute distinct v3/v3
build targets to point protodoc at.
Risk level: Low
Testing: Docs build, manual inspection.
Fixes#8087
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ac88316892cd47b6a9b58e3736e20e8863cd0d27
In which we convert every v3alpha reference to v3. In future revs of the
stable API versioning policy, we will develop better tooling to support
> 2 alpha and stable versions. For v3, it seems reasonable to just mv
v3alpha to v3, since there should be no external consumers yet.
Risk level: Low
Testing: bazel test //test/..., CI.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
Implements on-demand resolution of VirtualHosts via VHDS
Signed-off-by: Dmitri Dolguikh <ddolguik@redhat.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8e2d909ad22f84d9eb055f06890924a5879bad76
This patch introduces a new checker, tools/api/validate_structure.py, that is run as part of the
bazel.api CI job. It ensures that the package layout for the API doesn't violate some constraints,
largely reflecting the heuristics we used for v3alpha migration.
Along the way, I discovered there were some packages that were versionless and not boosted to
v3alpha, and there were some extensions left behind in envoy.config. These are fixed as well to
allow the validation to succeed.
Risk level: Low
Testing: tools/api/validate_structure.py passes, bazel test //test/...
Fixes#9580
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 29b30911dbfb3f9760efeb28238ceac36e1a1a23
Define empty config protos for all filters expecting google::protobuf::Empty
Risk Level: medium (change of config type)
Testing: unit
Docs Changes: done
Release Notes: define config protos for all extensions
Co-authored-by: Derek Argueta <dereka@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2d5a4e94720cc195324f79ca68f0e7a7dc83ee9e
Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ a60f6853a2c2ebbbfed79dfff0b5b644fd735980
This allows for a clean separation of config/service in v3. This is a
continuation of #9548.
Risk level: Low
Testing: bazel test //test/...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c3bddaee1912fcd1fedc4786aee830b2e4a7c599
Description:
Move packages around for #8120 and #8121
Risk Level: Med around messing up build.
Testing: CI
Docs Changes: in API/STYLE.md
Release Notes: N/A (v3alpha is not in use yet)
Fixes#8120
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 1371f2ef46582a72b5b3971147bd87c534011731
The type database now has rename information.
Also some misc. fixes for enum and generated static method handling
support.
Part of #8082
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2c8992bce1880ed7ae8ede837434b8713c24a615
As a source of entire Envoy version number. Will use this file in envoy
main repo as well.
By this change, document version string will be changed in development
version:
from: "1.6.0-data-plane-api-${GIT_SHA}"
to: "1.6.0.dev-data-plane-api-${GIT_SHA}"
And in release version, for example, in v1.6.0 release:
from: "1.6.0-tag-v1.6.0"
to: "tag-v1.6.0"
The significant change is dropping the first version number string like
"1.6.0-" in the release version document.
Signed-off-by: Taiki Ono <taiks.4559@gmail.com>
data-plane-api(CircleCI)
kmyerson
Taiki Ono
Kuat
Harvey Tuch