This PR adds BoringSSL private key API abstraction, as discussed in #6248. All comments and discussion is welcomed to get the API sufficient for most private key API tasks.
The PR contains the proposed API and the way how it can be used from ssl_socket.h. Also there is some code showing how the PrivateKeyMethodProvider is coming from TLS certificate config. Two example private key method providers are included in the tests.
Description: tls: support BoringSSL private key async functionality
Risk Level: medium
Testing: two basic private key provider implementation
Docs Changes: TLS arch doc, cert.proto doc
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9a3a234c3cd1f7b6707746d84eb74414b1990c73
Adds support for DNS SAN in ext authz peer validation
Risk Level: Low
Testing: Added
Docs Changes: Added
Release Notes: N/A
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ d4dc0a5b74acd42aafaaef8bb9c4ebed832674bd
Some BUILD files are missing build rules to generate go protos. envoyproxy/go-control-plane depends on these protos, so they should be exposed publicly. Added build rules to generate *.pb.go files.
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 @ c7110f8d10d928a3b18ee6a05439d7b4e49e595c
This adds the ability to specify dynamic metadata (by namespace) to
send with the ext_authz check request. This allows one filter to
specify information that can be then used in evaluating an
authorization decision.
Risk Level: Medium. Optional feature/extension of existing filter
Testing: Unit testing
Docs Changes: Inline in attribute_context.proto and ext_authz.proto
Fixes#7699
Signed-off-by: Ben Plotnick <plotnick@yelp.com>
Mirrored from https://github.com/envoyproxy/envoy @ d2e2cd6fa3dd7669f406ae11736f2e179213b449
Introduces a generic expression-based admission filter using https://github.com/google/cel-cpp.
This is a follow-up to discussion in https://github.com/envoyproxy/envoy/issues/6751.
The advantage of this approach is:
1. Un-opinionated about the policy structure since the only config is an expression. This is friendly towards control planes which can bear the complexity of translation, analysis, and evolution of policies.
2. Multi-language, CEL supports go, java, and c++ runtimes.
3. Inter-operability with other filters using request `metadata`. Companion filters can populate metadata about requests and resources that affect policy decisions.
4. Generic utility, it can be used for custom metric labels, access log entries, etc.
The dis-advantage of this approach is that its performance is lower than domain-optimized interpreters. On a fair example, the interpreter evaluates in around 1ms (see https://github.com/google/cel-cpp/blob/master/eval/tests/benchmark_test.cc#L591) vs ~150ns for hand-written C++ native code. There is space for improvement (especially if WASM can be used as a compilation target), but ultimately the generic expression form carries a cost.
Conditions are added to support RBAC filter for complementing the existing principal/permission model. They add support for the extended checks (e.g. time of query, resource-bound), but add no cost unless used.
Description: add expression-based admission filter
Risk Level: low
Testing:
Docs Changes:
Release Notes:
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f90e1b08ac5b4973c45a6529780ebdd211ff901f
As per #6651, this PR plumbs in CLI options to allow independent control over static/dynamic unknown
field validation.
The defaults are the same for static as today (strict) and for dynamic we are by default permissive.
This permits easy rollout of new API minor versions, including those related to security fixes.
Fixes a regression that occurred in #7200 where strict/permissive checking CLI options were
inverted.
As per #6818, added stats/warning for any unknown fields encountered.
Risk level: Low (strictly more permissive by default)
Testing: additional unit and integration tests added, exercising both permissive/strict checking
over various parts of the API (bootstrap, listeners, clusters, xDS, network filters, etc).
Fixes#6651Fixed#6818
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0418a855d9f9e37ec70b4c6d1942688fc8bb5751
Calling out that it's possible to use the value 0 to disable route timeout (as it is for idle timeout).
Signed-off-by: nmeessen <nmeessen@atlassian.com>
Mirrored from https://github.com/envoyproxy/envoy @ b9fe0b93371094827827b4932aaad09f89b14928
Description: Adds support for DNS SAN as Principal in RBAC filter.
Risk Level: Low
Testing: Added automated tests
Docs Changes: Updated
Release Notes: Added
Fixes#7836
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ 882a30677619856446f7e1b9d28c6ab319b21d1b
Omit the node identifier from subsequent discovery requests on the same stream.
Restricted to non-incremental xDS for tractability.
Risk Level: low, affects xDS protocol but guarded by an option
Testing: Unit/integration tests are updated
Docs Changes: xDS spec clarification
Release Notes: omit the node identifier from subsequent discovery requests
Fixes: #7860
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8e07e8297d7d5e68cf6d6d7e49ba98d2500cdef7
This change adds protections against flooding using PRIORITY
and/or WINDOW_UPDATE frames, as well as frames with an empty
payload and no end stream flag.
Fixes CVE-2019-9511, CVE-2019-9513 and CVE-2019-9518.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9f16bca5044260f5ceeb49c5836b9326a75a0b49
Limit the number of outbound (these, waiting to be written into the socket)
HTTP/2 frames. When the limit is exceeded the connection is terminated.
This mitigates flood exploits where a client continually sends frames that
are not subject to flow control without reading server responses.
Fixes CVE-2019-9512, CVE-2019-9514 and CVE-2019-9515.
Signed-off-by: Yan Avlasov <yavlasov@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b93886ca040795407efc641f8b41eaf35e7bf1bb
This warms when building:
> envoy/api/v2/cluster/filter.proto:12:1: warning: Import google/protobuf/struct.proto but not used.
Signed-off-by: Michael Rebello <me@michaelrebello.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7b0ce0d32a9b584626e8c16b5ae07817eade322d
Signed-off-by: Emil Mikulic <g-easy@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ c3a75316f2fa495fc7be36efd4f291445ac7b857
For the first point in #7771 for converting arbitrary protobuf value from header to metadata.
Risk Level: Low
Testing: Unit tests
Docs Changes: Updated version_history.rst
Release Notes: Updated version_history.rst
Signed-off-by: Yangmin Zhu <ymzhu@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9e552c5f0a86542eaae897d8f27bd34be85ad1df
Let the config override the Stackdriver address. This can be used for
proxying and testing.
Signed-off-by: Emil Mikulic <g-easy@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3e63182c3e74e0d517d2f0d1fc2ee950bbfe21e1
Signed-off-by: Daniel Hochman <danielhochman@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ c586af9d3f5940acc73d6a5fd0fdc2c521b6243d
Promote tracing operation field to listener level. This expands the scope of the field to support two use cases:
Tracing TCP connections: istio can send connection events to create a service communication graph. Network filters can benefit from the common knowledge about the intent of the listener/filter chain (client-side vs server-side).
Using ingress/egress designation for other telemetry. The direction of the traffic is a useful label on metrics, and it is not explicit at the moment, unless depending on tracing configuration in HTTP connection manager or naming convention. Both workarounds are not ideal.
Risk Level: low
Testing: all unit tests continue to pass
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ca2af9723598fab4f511b59407396cc5cff9ed94
Description: Fix missing gogo annotation. The file-level `equal_all` annotation was missing in one of the files and failed to compile in go-control-plane.
https://github.com/envoyproxy/go-control-plane/pull/201
Risk Level: Low
Testing: go-control-plane
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Shriram Rajagopalan <rshriram@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ bdd6788f1e01787d015eabd9902f4b565e5dea98
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
Description:
this commit bumps protoc-gen-validate to the latest version. this
should unblock `wrowe` in slack working on windows support.
after this I believe we can also take use of the new address validation
type to fix some unique error messages, but the first step is bumping it
as a side note:
- SocketState was using `.message.required` however it was not
a message type. as far as I can tell this was a bug that PGV fixed.
Risk Level: Low
Testing: Ensure that envoy successfully builds.
Docs Changes: None
Release Notes: None
Signed-off-by: Cynthia Coan <ccoan@instructure.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9c00735e68148b9100473eecce2ee536c3072c6b
Currently, in load_balancer_impl.cc: recalculatePerPriorityPanic(), even if common_lb_config.healthy_panic_threshold is 0%, a load balancer enters panic mode whenever normalized_total_availability is 0%.
I guess, a user who intentionally set to healthy_panic_threshold = 0 expects to immediately return error responses if there is no available host checked by a load balancer.
(In fact, current load_balancer_impl.cc: isGlobalPanic() decide not to enter panic mode whenever healthy_panic_threshold is 0%.)
So I suggest that panic mode is disabled only when healthy_panic_threshold is 0%.
I want this change for automatic degenerating lower priority or optional back-end services.
Risk Level: Low
(It seems that setting healthy_panic_threshold == 0 is a special case originally. It won't happen unless a user intend to disable panic mode, because default value of healthy_panic_threshold is 50%.)
Testing: unit and Integration tests with ./ci/run_envoy_docker.sh './ci/do_ci.sh bazel.release'
Docs Changes: inline
Signed-off-by: mnktsts2 <mnktsts2@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ ad9926fb29dc047d7583ab5b0217a3c379f14200
Signed-off-by: Emil Mikulic <g-easy@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ ea3ebca3b6d84a8b29c35ca03fa3666a0f4951c9
Description: Add an async data source which supports fetching data from local and remote data source. The async data provider guarantees that data is access before `init manager` is ready.
Risk Level: Low
Testing: Unit test
Docs Changes: N/A
Release Notes: Added
Fixes#7311
Signed-off-by: crazyxy <yxyan@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 42706efea87eda276cd650db99bc318319176a98
Description: Remove an unused dependency from tap. This makes a build warning go away.
Risk Level: low
Testing: build
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 101f8157fe06d78262d0b3c07cf1c2b7c8e72c98
In order to better support clients such as gRPC-LB that want to access
only a single listener/cluster, provide the scope in the xDS
specification to specify explicit resource hints.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7ef20d7609fb6f570a058fcf4b4e000922d7eeba
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
data-plane-api(CircleCI)