This PR wraps up #1319. The patch enables multiple TLS certificate
ingest for downstream TLS contexts, adds related unit and integration
tests, docs and release notes.
Risk Level: Low
Testing: Additional unit and integration tests. To avoid combinatorial
explosion, we validate mixed TLS v1.2/1.3 behavior in
ssl_integration_test only, and have more targeted certificate
selection tests in ssl_socket_Test.
Docs Changes: Added to architectural overview of TLS support.
Fixes#1319.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ fdb08806dc3d42bd3e3f9d467e526359689996af
This adds support for password encrypted private keys. The password is
to be supplied as a regular data source in the TlsCertificate
configuration.
Signed-off-by: Venil Noronha <veniln@vmware.com>
Mirrored from https://github.com/envoyproxy/envoy @ 94eb347914fc5812ee35c1c2a66c1784579bfb87
This PR starts to plumb multiple TLS certs from the proto level into the SSL context. We stop short
of enabling multiple TLS certificates, but instead have sufficient mechanism and interface changes
to propagate them to the SSL context. Future PRs will extend this with the SSL context
implementation.
Risk Level: Low
Testing: bazel test //test/...
Part of #1319.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9d1d959c5e8fc8e02754ea28e6cba9f7b1e3d1fc
Implement a new certificate validation context type CombinedCertificateValidationContext, which has a default CertificateValidationContextoption and SDS config. This default CertificateValidationContext will be merged with dynamic CertificateValidationContext into a new secret to serve. This is option 4 in https://docs.google.com/document/d/12gdjGN5m3v4vxUnDAglCP6pyyMoeuVGAGo7D_jc27jw/edit?usp=sharing
Risk Level: Low
Testing:
Docs Changes: NONE
Release Notes: NONE
Fixes: #4763
Signed-off-by: JimmyCYJ <jimmychen.0102@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7a651dc4d09ed07d6a5b5a40cc0809e3cf2e700e
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
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
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
*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
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
Added protos to support Role Based Access Control in Envoy.
Also removed existing auth.proto because the new RBAC proto is a replacement of it.
Ealier discussions at
envoyproxy/data-plane-api#586.
Signed-off-by: Limin Wang <liminwang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 13de384ab34428af99c53201f6b3c95991b7ae10
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>
data-plane-api(CircleCI)
Joe Friedl
Kuat
Piotr Sikora
Andrew Dunham