-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
External AuthZ C++ Data plane enablement #7459
Conversation
- Initial build-system changes to include definition of C++ stub services. - Added new target for ext_authz service. Signed-off-by: Nick A. Smith <[email protected]>
Signed-off-by: Nick A. Smith <[email protected]>
@lizan could you take a look at this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/retest
I believe the tsan failure is irrelevant.
api/envoy/api/v2/core/BUILD
Outdated
@@ -35,7 +35,7 @@ api_proto_library_internal( | |||
name = "base", | |||
srcs = ["base.proto"], | |||
visibility = [ | |||
":friends", | |||
"//visibility:public", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why did you need to change this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without the public visibility qualifier and given the bazel WORKSPACE extract shown below, the following error is encountered:
# Envoy API definitions
## We import envoy_api as a sub-repo of the mono-repo
git_repository(
name = "envoy",
branch = "data-plane",
remote = "https://github.com/thales-e-security/envoy.git",
verbose = True,
)
# Create @envoy_api virtual repository.
load("@envoy//bazel:api_repositories.bzl", "envoy_api_dependencies")
envoy_api_dependencies()
load("@envoy_api//bazel:repositories.bzl", "api_dependencies")
# api_dependencies() must be called first to import the correct versions of dependencies.
api_dependencies()
ERROR: xxx/.cache/bazel/_bazel_xxx/xxx/external/envoy_api/envoy/service/auth/v2/BUILD:5:1: in proto_library rule @envoy_api//envoy/service/auth/v2:attribute_context: target '@envoy_api//envoy/api/v2/core:base' is not visible from target '@envoy_api//envoy/service/auth/v2:attribute_context'. Check the visibility declaration of the former target if you think the dependency is legitimate
It appears https://github.com/envoyproxy/envoy/blob/master/api/envoy/api/v2/BUILD#L15 allows the external authz service definition to use types defined in base.proto. However, external implementers of https://github.com/envoyproxy/envoy/blob/master/api/envoy/service/auth/v2/external_auth.proto are not afforded the same rights.
The options I considered were:
- Make the contents of base.proto public
- Move the required types into another proto file and make that public.
The chose the former for simplicity as well as not wanting to cause significant rework for existing filters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I cannot reproduce your error with bazel 0.27.0 with a project importing envoy like
local_repository(
name = "envoy",
path = "/Users/lizan/github/lizan/envoy/7459",
)
load("@envoy//bazel:api_repositories.bzl", "envoy_api_dependencies")
envoy_api_dependencies()
load("@envoy//bazel:repositories.bzl", "GO_VERSION", "envoy_dependencies")
load("@envoy//bazel:cc_configure.bzl", "cc_configure")
envoy_dependencies()
load("@rules_foreign_cc//:workspace_definitions.bzl", "rules_foreign_cc_dependencies")
rules_foreign_cc_dependencies()
cc_configure()
load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
go_rules_dependencies()
go_register_toolchains(go_version = GO_VERSION)
The code in /Users/lizan/github/lizan/envoy/7459 contains this PR and reverted this line.
bazel build @envoy_api//envoy/service/auth/v2:external_auth_service_cc_grpc
works well too.
The visibility restriction is to avoid accidental unindented dependencies to core, so this shouldn't be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm. With bazel 0.25.2 and 0.27.1 on Linux I get the original error even with the WORKSPACE snippet provided. I'll dig more tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lizan you were right. I will revert to a visibility of :friends
.
🔨 rebuilding |
@nickrmc83 can you fix DCO by rebase or squash? otherwise LGTM. /wait |
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Gentle bump - |
Let's reopen this. And hope @nickrmc83 could help on fixing the DCO. |
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Subbed //visibility:public to :friends as per code review Signed-off-by: Nick Smith <[email protected]>
api/envoy/service/auth/v2/BUILD
Outdated
@@ -26,3 +26,11 @@ api_proto_library_internal( | |||
"//envoy/type:http_status", | |||
], | |||
) | |||
|
|||
api_cc_grpc_library( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can't we build this under the hood of api_proto_library_internal
, so we don't need to do explicit declaration for each of these? I'd prefer that things "just work" rather than having to boiler plate each individual thing we want to make a service consumable outside of Envoy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something I pondered. I opted for this route because I thought it was unlikely that most services would require CC protos and services. Is the preference to add to api_proto_library
a require_cc
option analogous to require_py
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I think that would be a good idea (the additional option). Maybe call it grpc_services
and make it a bool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@htuch and @lizan see latest changes whereby api_cc_grpc_library
and api_go_grpc_library
are used by api_proto_library
when has_services
is set. I've refactored some of the services so they make use of this change. Some services that are Go-specific have remained the same so they can specialize calls to api_go_grpc_library
as necessary.
`api_proto_library` will now enable the generatation of gRPC service stubs for Go and C++ if the `has_services` field is set. Updted services with Envoy-only dependencies to use new functionality removing now redundant `api_go_proto_library` declarations. Services with external dependencies have not been updated so that they can specialize `api_go_proto_library` declarations as necessary. Signed-off-by: Nick Smith <[email protected]>
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
This pull request has been automatically closed because it has not had activity in the last 14 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Signed-off-by: Nick Smith <[email protected]>
Looks like |
@nickrmc83 sorry to do this, but I'm going to merge #8003 first, since it also mucks with |
@nickrmc83 OK, #8003 is now merged; if you can merge master we can get this PR in as well, thanks again. |
This pull request has been automatically marked as stale because it has not had activity in the last 7 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
The metrics and trace APIs have external dependencies which are not yet handled when generating CC stubs. Signed-off-by: Nick A. Smith <[email protected]>
@htuch this should be good to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
This change defines C++ grpc bindings for the external AuthZ interface. In the istio Security WG we're planning on using this interface to provide transparent authentication of requests. As this interface lies on the data plane we wish to implement it in C++ to maintain consistent and predictable performance The changes allow a C++ implementation built using bazel to import Envoy as a workspace dependency and generate the C++ gRPC bindings directly without the need for complex import and generation scripts. Signed-off-by: Nick A. Smith <[email protected]>
This change defines C++ grpc bindings for the external AuthZ interface. In the istio Security WG we're planning on using this interface to provide transparent authentication of requests. As this interface lies on the data plane we wish to implement it in C++ to maintain consistent and predictable performance The changes allow a C++ implementation built using bazel to import Envoy as a workspace dependency and generate the C++ gRPC bindings directly without the need for complex import and generation scripts. Signed-off-by: Nick A. Smith <[email protected]>
This change defines C++ grpc bindings for the external AuthZ interface. In the istio Security WG we're planning on using this interface to provide transparent authentication of requests. As this interface lies on the data plane we wish to implement it in C++ to maintain consistent and predictable performance The changes allow a C++ implementation built using bazel to import Envoy as a workspace dependency and generate the C++ gRPC bindings directly without the need for complex import and generation scripts. Signed-off-by: Nick A. Smith <[email protected]>
Description:
This change defines C++ grpc bindings for the external AuthZ interface. In the istio Security WG we're planning on using this interface to provide transparent authentication of requests. As this interface lies on the data plane we wish to implement it in C++ to maintain consistent and predictable performance
The changes allow a C++ implementation built using bazel to import Envoy as a workspace dependency and generate the C++ gRPC bindings directly without the need for complex import and generation scripts.
Risk Level:
Medium
Testing:
N/A
Docs Changes:
N/A
Release Notes:
N/A