This was supposed to work already, but it wasn't due to a missing
call to X509_STORE_set_flags() and lack of test coverage.
*Risk Level*: Low
*Testing*: bazel test //test/...
*Docs Changes*: Added
*Release Notes*: Added
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 76278101ee854550cc29d8ba87db05e544b1f585
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
Refactor SdsApi to support dynamic certificate validation context, and support Envoy to fetch certificate validation context from remote server via SDS API.
Risk Level: Low
Testing: Unit tests and integration tests.
Fixes#1194
Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 15cfc5ad1a4d622126f642fa70699af753a2d310
SAN-based verification without trusted CA is insecure, since provided
values are easily spoofable.
Becasue of how the existing verification code is structured, this was
already enforced at run-time, and all certificates were rejected when
trusted CA wasn't specified, but previously it wasn't obvious why.
*Risk Level*: None
*Testing*: bazel test //test/...
*Docs Changes*: Added
*Release Notes*: n/a
Fixes#1268.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 72db143131c1030e7c448e034a1a08980dc826f9
No functional changes, only API update.
*Risk Level*: Low
*Testing*: bazel test //test/...
*Docs Changes*: n/a
*Release Notes*: n/a
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4eb09f86cbfff67404591cf812a7db8d7880c413
While there, add support for the standard hex-encoded SHA-256 hashes without colon delimiters.
Risk Level: Low
Testing: Unit tests added.
Docs Changes: Added
Release Notes: Added
Fixes#3418, #3419.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f7e1e23379fae6045546e63584435b78ae5f30e6
Previously, we would assert when we failed to set SNI for a socket. Now,
we reject the bad config.
Risk Level: Low
Testing: New ssl_socket_test.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3b084a7d747750cfcb868f0cce463af2fe4e781c
There are several main changes in this PR:
Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos.
Create individual packages for each filter and add independent versioning to each filter.
Add visibility constraints to prevent formation of dependency cycles.
Add gogoproto annotations to improve go code generation.
After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package.
The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane).
Added a few gogoproto annotations to improve golang code generation.
Signed-off-by: Kuat Yessenov <kuat@google.com>
In support of https://github.com/envoyproxy/envoy/issues/2200 and some
Google internal needs, we are planning on adding support to Envoy to
allow a configuration (or possibly build) driven decision on whether to
using the existing Envoy in-built Grpc::AsyncClient or
the Google C++ gRPC client library (https://grpc.io/grpc/cpp/index.html).
To move in this direction, the idea is we have the xDS ApiConfigSources,
rate limit service config and other filter configurations point at a
GrpcService object. This can be configured to use an Envoy cluster,
where Grpc::AsyncClient will orchestrate communication, or to contain
the config needed to establish a channel in Google C++ gRPC client
library.
Signed-off-by: Harvey Tuch <htuch@google.com>
CertificateValidationContext.trusted_ca is not only for client
certificates, but also for server certs. Change the wording to "peer
certificates".
Also mention that verification is not enabled by default in docs for
UpstreamTlsContext.
Signed-off-by: Peter Schultz <peter.schultz@classmarkets.com>
* Added PGV C++ generation support. This (hopefully temporarily)
abandons using native proto_library in favor of pgv_cc_proto_library.
We maintain build support for proto_library for the glorious future in
which we write a Bazel aspect to run PGV against the native
proto_library shadow graph.
* Replace min_len with min_bytes on strings, until PGV gets not-empty or
min_len support for C++.
* Various fixups for places where the PGV plugin objected to
annotations.
Signed-off-by: Harvey Tuch <htuch@google.com>
1) Do RDS other than rate limit. This is large enough will do that next.
2) Manually order top level in v2 with better titles
3) Random other fixes
Note also that I'm going to manually reorder the protos in some cases in a
follow up so the docs make a bit more sense for a casual reader.
Signed-off-by: Matt Klein <mklein@lyft.com>
This patch adds an overview page introduced the v2 API concepts via a
worked example. Brought in the entire transitive dep set of protos from
bootstrap.proto, none of these have been cleaned up beyond the minimum
required to have them build under Sphinx.
Also added the ability to link to the underlying proto in messages/enums
from protodoc.py generated RST.
Signed-off-by: Harvey Tuch <htuch@google.com>
oneof doesn't provide any namespace scoping, so the names looked
too generic where they're used in implementations.
Signed-off-by: Greg Greenway ggreenway@apple.com
SPKI doesn't change when certificate is reissued, so it works better
with short-lived certificates.
This is also the same format as used in HTTP Public Key Pinning.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
As previously pointed out in #9, the empty string is not generally a useful
value in the xDS APIs, so can be be considered equivalent to an unset
field. This is now documented in principles in #28 as well.
Also replace google.protobuf.BytesValue with bytes.
data-plane-api(CircleCI)
Joe Friedl
Kuat
Andrew Dunham
Matt Klein
htuch
Brian Pane
Piotr Sikora
Peter Schultz
alyssawilk
Greg Greenway