|
|
|
syntax = "proto3";
|
|
|
|
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
package envoy.config.rbac.v2;
|
|
|
|
|
|
|
|
option java_package = "io.envoyproxy.envoy.config.rbac.v2";
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
option java_outer_classname = "RbacProto";
|
|
|
|
option java_multiple_files = true;
|
|
|
|
|
|
|
|
import "envoy/api/v2/core/address.proto";
|
|
|
|
import "envoy/api/v2/route/route.proto";
|
|
|
|
import "envoy/type/matcher/metadata.proto";
|
|
|
|
import "envoy/type/matcher/string.proto";
|
|
|
|
|
filter: add conditions to access control filter (#7716)
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
5 years ago
|
|
|
import "google/api/expr/v1alpha1/syntax.proto";
|
|
|
|
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
import "validate/validate.proto";
|
|
|
|
|
|
|
|
// [#protodoc-title: Role Based Access Control (RBAC)]
|
|
|
|
|
|
|
|
// Role Based Access Control (RBAC) provides service-level and method-level access control for a
|
|
|
|
// service. RBAC policies are additive. The policies are examined in order. A request is allowed
|
|
|
|
// once a matching policy is found (suppose the `action` is ALLOW).
|
|
|
|
//
|
|
|
|
// Here is an example of RBAC configuration. It has two policies:
|
|
|
|
//
|
|
|
|
// * Service account "cluster.local/ns/default/sa/admin" has full access to the service, and so
|
|
|
|
// does "cluster.local/ns/default/sa/superuser".
|
|
|
|
//
|
|
|
|
// * Any user can read ("GET") the service at paths with prefix "/products", so long as the
|
|
|
|
// destination port is either 80 or 443.
|
|
|
|
//
|
|
|
|
// .. code-block:: yaml
|
|
|
|
//
|
|
|
|
// action: ALLOW
|
|
|
|
// policies:
|
|
|
|
// "service-admin":
|
|
|
|
// permissions:
|
|
|
|
// - any: true
|
|
|
|
// principals:
|
|
|
|
// - authenticated:
|
|
|
|
// principal_name:
|
|
|
|
// exact: "cluster.local/ns/default/sa/admin"
|
|
|
|
// - authenticated:
|
|
|
|
// principal_name:
|
|
|
|
// exact: "cluster.local/ns/default/sa/superuser"
|
|
|
|
// "product-viewer":
|
|
|
|
// permissions:
|
|
|
|
// - and_rules:
|
|
|
|
// rules:
|
|
|
|
// - header: { name: ":method", exact_match: "GET" }
|
|
|
|
// - header: { name: ":path", regex_match: "/products(/.*)?" }
|
|
|
|
// - or_rules:
|
|
|
|
// rules:
|
|
|
|
// - destination_port: 80
|
|
|
|
// - destination_port: 443
|
|
|
|
// principals:
|
|
|
|
// - any: true
|
|
|
|
//
|
|
|
|
message RBAC {
|
|
|
|
// Should we do safe-list or block-list style access control?
|
|
|
|
enum Action {
|
|
|
|
// The policies grant access to principals. The rest is denied. This is safe-list style
|
|
|
|
// access control. This is the default type.
|
|
|
|
ALLOW = 0;
|
|
|
|
|
|
|
|
// The policies deny access to principals. The rest is allowed. This is block-list style
|
|
|
|
// access control.
|
|
|
|
DENY = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The action to take if a policy matches. The request is allowed if and only if:
|
|
|
|
//
|
|
|
|
// * `action` is "ALLOWED" and at least one policy matches
|
|
|
|
// * `action` is "DENY" and none of the policies match
|
|
|
|
Action action = 1;
|
|
|
|
|
|
|
|
// Maps from policy name to policy. A match occurs when at least one policy matches the request.
|
|
|
|
map<string, Policy> policies = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Policy specifies a role and the principals that are assigned/denied the role. A policy matches if
|
|
|
|
// and only if at least one of its permissions match the action taking place AND at least one of its
|
filter: add conditions to access control filter (#7716)
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
5 years ago
|
|
|
// principals match the downstream AND the condition is true if specified.
|
|
|
|
message Policy {
|
|
|
|
// Required. The set of permissions that define a role. Each permission is matched with OR
|
|
|
|
// semantics. To match all actions for this policy, a single Permission with the `any` field set
|
|
|
|
// to true should be used.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
repeated Permission permissions = 1 [(validate.rules).repeated = {min_items: 1}];
|
|
|
|
|
|
|
|
// Required. The set of principals that are assigned/denied the role based on “action”. Each
|
|
|
|
// principal is matched with OR semantics. To match all downstreams for this policy, a single
|
|
|
|
// Principal with the `any` field set to true should be used.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
repeated Principal principals = 2 [(validate.rules).repeated = {min_items: 1}];
|
filter: add conditions to access control filter (#7716)
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
5 years ago
|
|
|
|
|
|
|
// An optional symbolic expression specifying an access control
|
|
|
|
// :ref:`condition <arch_overview_condition>`. The condition is combined
|
|
|
|
// with the permissions and the principals as a clause with AND semantics.
|
filter: add conditions to access control filter (#7716)
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
5 years ago
|
|
|
google.api.expr.v1alpha1.Expr condition = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Permission defines an action (or actions) that a principal can take.
|
|
|
|
// [#next-free-field: 10]
|
|
|
|
message Permission {
|
|
|
|
// Used in the `and_rules` and `or_rules` fields in the `rule` oneof. Depending on the context,
|
|
|
|
// each are applied with the associated behavior.
|
|
|
|
message Set {
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
repeated Permission rules = 1 [(validate.rules).repeated = {min_items: 1}];
|
|
|
|
}
|
|
|
|
|
|
|
|
oneof rule {
|
|
|
|
option (validate.required) = true;
|
|
|
|
|
|
|
|
// A set of rules that all must match in order to define the action.
|
|
|
|
Set and_rules = 1;
|
|
|
|
|
|
|
|
// A set of rules where at least one must match in order to define the action.
|
|
|
|
Set or_rules = 2;
|
|
|
|
|
|
|
|
// When any is set, it matches any action.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
bool any = 3 [(validate.rules).bool = {const: true}];
|
|
|
|
|
|
|
|
// A header (or pseudo-header such as :path or :method) on the incoming HTTP request. Only
|
|
|
|
// available for HTTP request.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.route.HeaderMatcher header = 4;
|
|
|
|
|
|
|
|
// A CIDR block that describes the destination IP.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.core.CidrRange destination_ip = 5;
|
|
|
|
|
|
|
|
// A port number that describes the destination port connecting to.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
uint32 destination_port = 6 [(validate.rules).uint32 = {lte: 65535}];
|
|
|
|
|
|
|
|
// Metadata that describes additional information about the action.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
type.matcher.MetadataMatcher metadata = 7;
|
|
|
|
|
|
|
|
// Negates matching the provided permission. For instance, if the value of `not_rule` would
|
|
|
|
// match, this permission would not match. Conversely, if the value of `not_rule` would not
|
|
|
|
// match, this permission would match.
|
|
|
|
Permission not_rule = 8;
|
|
|
|
|
|
|
|
// The request server from the client's connection request. This is
|
|
|
|
// typically TLS SNI.
|
|
|
|
//
|
|
|
|
// .. attention::
|
|
|
|
//
|
|
|
|
// The behavior of this field may be affected by how Envoy is configured
|
|
|
|
// as explained below.
|
|
|
|
//
|
|
|
|
// * If the :ref:`TLS Inspector <config_listener_filters_tls_inspector>`
|
|
|
|
// filter is not added, and if a `FilterChainMatch` is not defined for
|
|
|
|
// the :ref:`server name <envoy_api_field_listener.FilterChainMatch.server_names>`,
|
|
|
|
// a TLS connection's requested SNI server name will be treated as if it
|
|
|
|
// wasn't present.
|
|
|
|
//
|
|
|
|
// * A :ref:`listener filter <arch_overview_listener_filters>` may
|
|
|
|
// overwrite a connection's requested server name within Envoy.
|
|
|
|
//
|
|
|
|
// Please refer to :ref:`this FAQ entry <faq_how_to_setup_sni>` to learn to
|
|
|
|
// setup SNI.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
type.matcher.StringMatcher requested_server_name = 9;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Principal defines an identity or a group of identities for a downstream subject.
|
|
|
|
// [#next-free-field: 9]
|
|
|
|
message Principal {
|
|
|
|
// Used in the `and_ids` and `or_ids` fields in the `identifier` oneof. Depending on the context,
|
|
|
|
// each are applied with the associated behavior.
|
|
|
|
message Set {
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
repeated Principal ids = 1 [(validate.rules).repeated = {min_items: 1}];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Authentication attributes for a downstream.
|
|
|
|
message Authenticated {
|
|
|
|
reserved 1;
|
|
|
|
|
|
|
|
// The name of the principal. If set, The URI SAN or DNS SAN in that order is used from the
|
|
|
|
// certificate, otherwise the subject field is used. If unset, it applies to any user that is
|
|
|
|
// authenticated.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
type.matcher.StringMatcher principal_name = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
oneof identifier {
|
|
|
|
option (validate.required) = true;
|
|
|
|
|
|
|
|
// A set of identifiers that all must match in order to define the downstream.
|
|
|
|
Set and_ids = 1;
|
|
|
|
|
|
|
|
// A set of identifiers at least one must match in order to define the downstream.
|
|
|
|
Set or_ids = 2;
|
|
|
|
|
|
|
|
// When any is set, it matches any downstream.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
bool any = 3 [(validate.rules).bool = {const: true}];
|
|
|
|
|
|
|
|
// Authenticated attributes that identify the downstream.
|
|
|
|
Authenticated authenticated = 4;
|
|
|
|
|
|
|
|
// A CIDR block that describes the downstream IP.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.core.CidrRange source_ip = 5;
|
|
|
|
|
|
|
|
// A header (or pseudo-header such as :path or :method) on the incoming HTTP request. Only
|
|
|
|
// available for HTTP request.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.route.HeaderMatcher header = 6;
|
|
|
|
|
|
|
|
// Metadata that describes additional information about the principal.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
type.matcher.MetadataMatcher metadata = 7;
|
|
|
|
|
|
|
|
// Negates matching the provided principal. For instance, if the value of `not_id` would match,
|
|
|
|
// this principal would not match. Conversely, if the value of `not_id` would not match, this
|
|
|
|
// principal would match.
|
|
|
|
Principal not_id = 8;
|
|
|
|
}
|
|
|
|
}
|