* api: add proto options for java
* add ci for checking proto options
Signed-off-by: Penn (Dapeng) Zhang <zdapeng@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 02659d411332e9f20d229f482931c15304ea17fd
This change allows user to configure custom authority headers to be
sent with gRPC health checks. It defaults to the name of the cluster,
thus maintaining backward compatibility.
Signed-off-by: Yuan Liu <yuan@stripe.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6af566f536fe03afed2823622fad075a73d7e385
Description: Allow envoy to proxy metadata in responses.
Risk Level: Low. Not used.
Testing: Integration test. (Unit tests will be added with filters)
Docs Changes: inline
Release Notes: n/a
Part of #2394
Signed-off-by: Yang Song <yasong@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b6ff832b9159fad4aef3e93d6243753f9427494c
Currently health check failure events are only log if the HealthFlag for a host transition from non-FAILED_ACTIVE_HC to FAILED_ACTIVE_HC. However, since hosts are initialized in the FAILED_ACTIVE_HC state, hosts that never became healthy have no events associated with it.
Since the current health check events only log transitions, we'll have to scan the entire log in order to find the hosts in a current failing state. Then we'll still have to filter the hosts permanently removed from the cluster by the discovery service. This makes the events very difficult to use in operations.
Proposed solution
Both of these 2 issues can be solved by emitting a health check failure event if either of these conditions are true:
If the active health check failed and it's the first health check for a host. This ensures we have events for hosts that never became healthy.
If the active health check failed and a AlwaysLogFailures configuration is set to true, by default this flag is set to false. This makes it very easy to find the hosts currently failing by looking at the last few seconds of logs.
Signed-off-by: Henry Yang <hyang@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 11e196b67ee9124f33c45f5adf542841386e3c39
API for #4475.
Risk Level: Low (not implemented)
Testing: CI
Docs Changes: Added but hided
Release Notes: N/A, will add when adding impl.
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 45a460fabf34698a875060482de96f7f618bdc9f
Implements rate limiting for discovery requests
Risk Level: Medium. This changes the way DiscoveryRequests are processed today (queues them) and adds rate limiting behaviour. While we have good test coverage (and also additional tests have been added), there is some risk.
Testing: Automated tests
Docs Changes: N/A
Release Notes: Added
Fixes#4718
Signed-off-by: Rama <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ 455714694bb930729c32a1f92c0f9c4f083a3bdb
The main difference between what we had and official nghttp2 support is lack of support for upgrade-with-bodies (on request or response path). Adjusted header munging, tests, and docs accordingly.
Risk Level: Low (changes code on a "hidden" code path)
Testing: updated tests, new unit tests
Docs Changes: updated
Release Notes: noted H2 websocket support
Fixes#1630
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 5b9de64f2858439b7c3b6ddabc08f50f4a752b90
A fuzz failure indicated a divide-by-zero in HealthCheckerImplBase::interval(). Beyond this, on
inspection, it seems we allow zero retry intervals, which can live lock the main thread. This PR
fixes these issues.
Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=10786.
Risk Level: Low
Testing: Additional unit test and a corpus entry added.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b61b28fe7ae9927452477a0f4e337c53830a7070
limiting user defined header alterations to 25 alterations (add/remove request/response headers) and 1024 bytes per alteration.
Risk Level: medium (if someone needs higher limits we can roll back and roll forward with new values)
Testing: new unit tests of one of the 17 fields affected
Release Notes: noted the new limitations
Fixes#4268
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ b9bee1e649399f838b23cb1cedfba888e1925605
This patch reintroduces PR #4217.
Signed-off-by: Tony Allen <tallen@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ bcc7a96d9e66bc0f70e3ed52161ec3471f835bdb
This reverts commit 75e54d072fa190ab78b9795f9ed7a98e1d2d33a3.
This was breaking Mac CI due to known PGV CLI limits.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8ba41eea553232bdfab90d9aa32ab4b72ca6fb31
While there, move header modification in some tests from
route action level (deprecated in #3838) to route level.
*Risk Level*: Low
*Testing*: bazel test //test/...
*Docs Changes*: Added
*Release Notes*: Added
Fixes#4249.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6ce3e1f45005c37e4a951470ee0bcf0381738e76
To encourage users to use v2 configuration. Related to #2100.
Risk Level: N/A, documentation change.
Testing: N/A
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Taiki Ono <taiki-ono@cookpad.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1d46c75024ebe3c5449647f8bbb9d5dcc532f836
Add a new field local_credentail into GoogleGrpc which supports Envoy to use gRPC local channel credentials.
Updated gRPC library to 1.15.0 release, which provides new methods that we need in order to use local channel credentials. See grpc/grpc#15909.
Certain Google gRPC features, such as passing Google default call credential, only works with a valid channel credential. Local credential is a valid channel credential.
Risk Level: Low
Testing: Unit test
Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 23e8e12fd77b08b87007a819b5683a5289883b46
This allows tunneling over H2, unfortunately only enabled via nghttp2_option_set_no_http_messaging until nghttp2/nghttp2#1181 is sorted out. See the big warnings about not using (at least without knowing you're going to have a roll-out that may break backwards-compatibility some time in the not too distant future)
Risk Level: Medium (changes are contained behind H2-with-Upgrade header which doesn't work today)
Testing: unit tests, and turned up the full H1/H2 upstream/downstream in the integration test
Docs Changes: for now, though I may take them out. I think they're useful for review.
Release Notes: not added since we don't want folks using it (outside of testbeds) yet.
#1630
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ cd171d9a95f551628453c83f0b00924e8b310bf0
We have dedicated alternative mechanisms for this in RouteAction, it can
confuse other actions (e.g. prefix_rewrite).
Fixes oss-fuzz issue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9995.
Risk level: Low
Testing: Unit tests and corpus entry added.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b9dc5d9a04411fe72ff516cbaef527dd8c016ae9
The existing RestApiFetcher implementation used a hard-coded request
timeout of 1s which wouldn't suit all environments. This commit enables
the configuration of request timeout in the RestApiFetcher.
Signed-off-by: Venil Noronha <veniln@vmware.com>
Mirrored from https://github.com/envoyproxy/envoy @ a3364380ae8dbfac692977f3d5a846b7498eb4ba
Some sites where we consume HeaderValue, e.g. in Google gRPC client library metadata, require
non-empty keys as a precondition. This seems a general property; there shouldn't be any use case for
a header key that is empty.
Found with server_fuzz_test under oss-fuzz (issue 9373). As a bonus, also fixed another proto
descriptor crash that occurs with this corpus addition due to missing proto descriptor pool entries
in server_fuzz_test.
Risk level: Low
Testing: New server_fuzz corpus entry.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8ed7c157c4b672763ae74e526e69ef43dda52549
adds the required visibility rules and delegates the rest to the generic
api_proto_library. I tested the change by doing the following without
getting errors.
./ci/run_envoy_docker.sh './ci/do_ci.sh docs'
I changed the BUILD files using the following commands.
/envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/api_proto_library(/api_proto_library_internal(/g'
envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/"api_proto_library"/"api_proto_library_internal"/g'
Signed-off-by: mickey <mickeyju@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4b871c0ab9350882271a490adcee44e613ed9807
This PR extends the current Ext_Authz filter to allow optional HTTP attributes being passed from the Authorization service down to client or, to the upstream services. I would like to get some feedback on the changes to the current gRPC async client and filter before moving to implementation of HTTP part of this extension and tests.
*issue: #2828
Risk Level: Medium
Testing: Manual, unit testing.
Docs Changes: envoyproxy/data-plane-api#563
Signed-off-by: Gabriel <gsagula@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5244597e93c70b4945c03a9fc55f8924a2da6fbc
This allows users to specify literal socket options that may not be compatible with upstream kernels or available in precompiled Envoy binaries.
Risk Level: Low
Testing:
Existing tests pass plus new test to cover new functionality.
Partial fix for #3661.
Signed-off-by: Trevor Schroeder <trevors@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 20c0454545761c254180f77948304083406757be
This supports things like OAuth, GCE default creds, refresh tokens, etc.
Risk Level: Low
Testing: Minimal tests. grpc::Channel/CallCredentials are opaque and don't provide much in the way
of inspection from tests (CC: @vjpai).
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2426ec1c614399438fae6803c85d22b98b1a7038
*Risk Level*: None
*Testing*: bazel test //test/...
*Docs Changes*: n/a
*Release Notes*: n/a
Found with buildifier.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e8964c83f359916ecbf9c01a03ade3c92aac479
The main gRPC service message is no longer draft.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ ef4d1b1392cf9e6e124b154bc481b1452690e157
The default is actually the cluster name, not the ip
Signed-off-by: Snow Pettersen <snowp@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2fa152da07db067cb0aedd1ef309759cb9424de6
This change makes it possible to create custom Google gRPC channel credentials to be used for communication with the control plane. The current implementation only supports mutual TLS.
Risk Level: Low: optional feature, no functional change unless specifically overridden
Testing: additional unit tests.
Mirrored from https://github.com/envoyproxy/envoy @ b31452e724b024742719f16cd9adc7c8915f8c36
Adds TCP Keepalive support for upstream connections. This can be configured on the cluster manager level, and overridden on the cluster level.
Risk Level: Medium
Testing:
Unit tests have been added. It appears to run and work.
Docs Changes:
envoyproxy/data-plane-api#614Fixesenvoyproxy/envoy#3028
API Changes:
envoyproxy/data-plane-api#614
Signed-off-by: Jonathan Oddy <jonathan.oddy@transferwise.com>
Mirrored from https://github.com/envoyproxy/envoy @ dd953f99945bb7c6b3251f71bffe252a5f6e9e62
This was found via proto fuzzing the server config.
Risk Level: Low
Testing: New utility_test.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ a87d265d1c1819926f2b2e8e7e866244fd40f574
This unhides request headers to add field for HTTP health check and put a
release note line in the version history.
Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
This PR includes the necessary modifications in support of envoyproxy/envoy#2828.
Added additional configuration to ext_authz.proto so that the filter is able to call an HTTP/1.1 authorization service.
In external_auth.proto, added a nested message to CheckResponse that allows the authorization service to pass additional HTTP response attributes back to the authz filter.
Signed-off-by: Gabriel <gsagula@gmail.com>
data-plane-api(CircleCI)
Marcelo Juchem
htuch
Dhi Aurrahman
Gabriel Sagula