This fixes the refs in protos and removes the sed operations for build
The benefits are:
- less indirection in proto refs
- (small) speedup of build
- simplify docs build
- simplify reuse of proto comments (eg generating jsonschemas)
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 45ec050f91407147ed53a999434b09ef77590177
Adding a deprecated API version annotation to deprecated fields and enum values in proto files.
This is part of the work on adding minor/patch versioning work.
Risk Level: Low (adding annotation to existing protos).
Testing: Added and modified tests for the tooling (in tools/testdata).
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5a8bfa20dc3c85ecb61826d122696ecaa75dffa0
This replaces prior logic where the :scheme header was consistently overwritten based on the encryption level of the upstream connection.
Risk Level: High (l7 change)
Testing: new integration tests, unit tests
Docs Changes: api docs updated
Release Notes: inline
Runtime guard: envoy.reloadable_features.preserve_downstream_scheme
Part of #14587
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 8ac28e233538f0636b6e079f9d5569707b0ca815
Support adding response headers on OK authorization checks from ext_authz
Commit Message: ext_authz: support response headers on OK authorization checks
Additional Description:
Risk Level: low (opt-in feature, does nothing by default)
Testing: Added code to existing unit tests
Docs Changes: API protos documented
Release Notes: ext_authz: added :ref:`response_headers_to_add <envoy_v3_api_field_service.auth.v3.OkHttpResponse.response_headers_to_add>` to support sending response headers to downstream clients on OK external authorization checks.
Platform Specific Features:
Fixes#7986
Signed-off-by: John Esmet <john.esmet@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ ac9a2637336decdcc52c24add5e8fc39edebb962
Scheme is populated for h2 and not for h1.1.
Advise accordingly in documentation.
Signed-off-by: Harry Bagdi <harrybagdi@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 973a25abf42d580ef375e10f6a36bbe0c1038d2c
1) Some intro text felt out of date as well as minor changes to
the overall flow.
2) Small fix to extauth docs from recent issue.
3) Remove ambassador/gloo docs. Almost definitely out of date and
don't belong anymore given how many things consume Envoy.
4) Remove TapDS. It was never implemented and would never be
implemented given ECDS.
5) Fix release notes from stable releases.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 50e722cbb0486268c128b0f1d0ef76217387799f
Add support for the letting the authorization service tell Envoy which auth related headers to remove once the authorization server is done with them, so that the upstream does not see them.
Signed-off-by: Martin Matusiak <numerodix@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 228c8ad78433c19b61eeaf9aad1c38ec1f2c75cc
This adds a dynamic_metadata field to CheckResponse message, hence it can be used for any type of HTTP response (OkHttpResponse or DeniedHttpResponse).
Risk Level: Low
Testing: Updated
Docs Changes: Updated
Release Notes: Added
Fixes#12671
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ cbdd01c22b84ac5333f95f030821dfcf6db49734
This patch enables ext_authz backed with gRPC service to emit metadata.
The authorization can set the dynamic metadata (an opaque
google.protobuf.Struct) as part of the `CheckResponse` when it is
successful (i.e. when `http_response` is `OkHttpResponse`).
Signed-off-by: Dhi Aurrahman <dio@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ ff44d731ecc8d744b971b31aec816ad0b56bad42
This patch performs a major version freeze and bump by modifying
package_version_status, using the tooling developed in #10636.
Specifically:
v2 APIs are frozen (except for where they are the latest in their
package history and still active)
v3 APIs are transitioned to be active
Candidate v4alpha APIs are generated (not used by Envoy yet)
Fixes#10355
Risk level: medium (entire API's files are modified, visually verified
to ensure things look sane, all tests pass)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 549164c42cae84b59154ca4c36009e408aa10b52
Part of https://github.com/envoyproxy/envoy/issues/10355, this patch introduces additional
annotations to the API to support automatic inference (and developer documentation) of where the
active developer editable version of a file is, and which files are frozen or machine generated.
Risk level: Low (API annotations only)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4c5f4310bb8a19a38e5377d7a2d2dc6aa4560f47
In which we convert every v3alpha reference to v3. In future revs of the
stable API versioning policy, we will develop better tooling to support
> 2 alpha and stable versions. For v3, it seems reasonable to just mv
v3alpha to v3, since there should be no external consumers yet.
Risk level: Low
Testing: bazel test //test/..., CI.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
data-plane-api(Azure Pipelines)