This PR avoids having to include an API type database in the Envoy build
by introducing a message annotation option that allows Envoy to
determine earlier corresponding message types via descriptor inspection.
The ApiTypeDb is now ApiTypeOracle and utilizes these annotations.
Risk level: Low
Testing: Existing API and verison upgrade tests pass.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 297f7a73b3f93bccf8af73c0a555ae52bce6cecb
Deprecate google.protobuf.Struct config members in the following types:
envoy.api.v2.auth.PrivateKeyProvider
envoy.api.v2.listener.UdpListenerConfig
envoy.config.filter.accesslog.v2.ExtensionFilter
Risk Level: Low
Testing: Unit Test
Docs Changes: N/A
Release Notes: N/A
Fixes: #8403
Signed-off-by: Yan Avlasov <yavlasov@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d36adbb5c4aad13af21f109b86978b8478f54409
Generate or format next free field annotation via protoxform.
Risk Level: low
Testing: N/A
Docs Changes: N/A
Release Notes: N/A
Fixes#8429
Signed-off-by: Yi Tang <ssnailtang@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 986173ed516dcc1c3dea7db90659ed993d0aad75
This patch moves away from the paradigm of sed-style upgrading of every v2
package to v3alpha. Instead, an additional type analysis phase is
performed prior to protoxform by a protoc plugin known as the "type
whisperer".
The type whisperer produces structured type dependency information for
each .proto. The tools/type_whisperer/typedb_gen.py tool then knits
these together to provide an API-wide type dependency graph. This is
then used to determine which types need upgrading (either they have
breaking changes or transitively depend on types with such changes).
Only packages with upgraded types now undergo the v2 -> v3alpha
transition.
The API type database is checked into
source/common/config/api_type_db.pb. This may seem a strange location,
but in the future we will include the type database as a build artifact
for the Envoy binary, as it will be used by the reflection-based version
converter to find the type upgrade path for input proto.
Risk level: Low (the v3alpha protos are not used yet).
Testing: fix_format, manual inspection of diffs, bazel test //test/...,
docs build.
Part of #8082Fixes#8490
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ad57b58cfbb256af41a467260dce2a8013b7a7fa
* [#not-implemented-warn:] was barely used and its purposes are better
served by [#not-implemented-hide:].
* [#proto-status:] was there for an earlier style of versioning, where
APIs were "frozen" or "draft", etc. Now we have semantic versioning
and a regular API clock as per #6271.
Part of #8371.
Risk level: Low (docs only).
Testing: Docs rebuild.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2c4b6f2b3d614a15f312e34f4664ebeb96d07d12
Via ./api/migration/v3alpha.sh. This picks up the changes since the last
sync, in particular the major reformat in #8309.
Risk level: Low (not used yet).
Testing: bazel build @envoy_api//...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c41cfbf6a33b8115a7e29a2b4a926aad4cd062be
This existed for the v1 -> v2 migration and is no longer relevant.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 358793bce7a0a3eb41f4d9961da5c61b374ceb7d
Remove gogoproto annotations. They can be replaced with a custom gogoproto compiler (e.g. something like https://github.com/gogo/googleapis/tree/master/protoc-gen-gogogoogleapis). I have an experimental version of it to validate that it's possible to re-apply important annotations in the compiler.
Risk Level: low
Testing: builds
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e7f0b7176efdc65f96eb1697b829d1e6187f4502
Fixes#7982
Defines a package level proto library and its associated internal go_proto_library.
Deletes all existing api_go_proto_library, api_go_grpc_library, and go_package annotations in protos (they are not required and pollute the sources).
I deliberately avoided touching anything under udpa since it's being moved to another repository.
Risk Level: low
Testing: build completes
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d504fde0ffd97017d1ddff8caa9a3b46bba9ae48
This patch establishes a v3alpha baseline API, by doing a simple copy of
v2[alpha] dirs and some sed-style heuristic fixups of BUILD dependencies
and proto package namespaces.
The objective is provide a baseline which we can compare the output from
tooling described in #8083 in later PRs, providing smaller visual diffs.
The core philosophy of the API migration is that every step will be
captured in a script (at least until the last manual steps),
api/migration/v3alpha.sh. This script will capture deterministic
migration steps, allowing v2[alpha] to continue to be updated until we
finalize v3.
There is likely to be significant changes, e.g. in addition to the work
scoped for v3, we might want to reduce the amount of API churn by
referring back to v2 protos where it makes sense. This will be done via
tooling in later PRs.
Part of #8083.
Risk level: Low
Testing: build @envoy_api//...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 085d72b490c124a02849812798f5513a8df9ae72
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
Co-Authored-By: Nguyen Phuong An <AnNP@vn.fujitsu.com>
Signed-off-by: Kim Bao Long <longkb@vn.fujitsu.com>
Mirrored from https://github.com/envoyproxy/envoy @ 445fdd01ad460a2af28870d65caaa75b5b8922b5
* 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
No functional changes.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 58bf369ab877058f7ee24d1ed9212b26a7f04c41
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
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>
data-plane-api(CircleCI)
Joe Friedl
Kuat
Andrew Dunham
Matt Klein
htuch
Brian Pane