Skip to content
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

Merged
merged 19 commits into from
Sep 16, 2019
Merged

External AuthZ C++ Data plane enablement #7459

merged 19 commits into from
Sep 16, 2019

Conversation

nickrmc83
Copy link
Contributor

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

Nick A. Smith added 2 commits June 10, 2019 10:56
- Initial build-system changes to include definition of C++ stub
services.
- Added new target for ext_authz service.

Signed-off-by: Nick A. Smith <nick.a.smith@thalesesecurity.com>
Signed-off-by: Nick A. Smith <nick.a.smith@thalesesecurity.com>
@junr03
Copy link
Member

junr03 commented Jul 3, 2019

@lizan could you take a look at this?

Copy link
Member

@lizan lizan left a 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.

@@ -35,7 +35,7 @@ api_proto_library_internal(
name = "base",
srcs = ["base.proto"],
visibility = [
":friends",
"//visibility:public",
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

@repokitteh-read-only
Copy link

🔨 rebuilding ci/circleci: tsan (failed build)

🐱

Caused by: a #7459 (review) was submitted by @lizan.

see: more, trace.

@lizan
Copy link
Member

lizan commented Jul 11, 2019

@nickrmc83 can you fix DCO by rebase or squash? otherwise LGTM.

/wait

@stale
Copy link

stale bot commented Jul 19, 2019

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!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Jul 19, 2019
@stale
Copy link

stale bot commented Jul 26, 2019

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!

@stale stale bot closed this Jul 26, 2019
@sungsk
Copy link

sungsk commented Jul 29, 2019

Gentle bump -
This PR seems ready to be merged, but was closed due to staleness. Can we expect this to be merged soon?

@dio
Copy link
Member

dio commented Jul 29, 2019

Let's reopen this. And hope @nickrmc83 could help on fixing the DCO.

@dio dio reopened this Jul 29, 2019
@stale stale bot removed the stale stalebot believes this issue/PR has not been touched recently label Jul 29, 2019
@stale
Copy link

stale bot commented Aug 5, 2019

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!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Aug 5, 2019
Subbed //visibility:public to :friends as per code review

Signed-off-by: Nick Smith <nick.a.smith@thalesesecurity.com>
@stale stale bot removed the stale stalebot believes this issue/PR has not been touched recently label Aug 6, 2019
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #7459 was synchronize by nickrmc83.

see: more, trace.

@htuch htuch self-assigned this Aug 7, 2019
@@ -26,3 +26,11 @@ api_proto_library_internal(
"//envoy/type:http_status",
],
)

api_cc_grpc_library(
Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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 <nick.a.smith@thalesesecurity.com>
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.
CC @envoyproxy/udpa-wg: FYI only for changes made to api/udpa/.

🐱

Caused by: #7459 was synchronize by nickrmc83.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.
CC @envoyproxy/udpa-wg: FYI only for changes made to api/udpa/.

🐱

Caused by: #7459 was synchronize by nickrmc83.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.
CC @envoyproxy/udpa-wg: FYI only for changes made to api/udpa/.

🐱

Caused by: #7459 was synchronize by nickrmc83.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.
CC @envoyproxy/udpa-wg: FYI only for changes made to api/udpa/.

🐱

Caused by: #7459 was synchronize by nickrmc83.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.
CC @envoyproxy/udpa-wg: FYI only for changes made to api/udpa/.

🐱

Caused by: #7459 was synchronize by nickrmc83.

see: more, trace.

@stale
Copy link

stale bot commented Aug 26, 2019

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!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Aug 26, 2019
@stale
Copy link

stale bot commented Sep 2, 2019

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!

@stale stale bot closed this Sep 2, 2019
@nickrmc83
Copy link
Contributor Author

nickrmc83 commented Sep 2, 2019

@htuch and @lizan This branch has just been updated with the final merge from master and so is ready to go.

@htuch htuch reopened this Sep 3, 2019
@stale stale bot removed the stale stalebot believes this issue/PR has not been touched recently label Sep 3, 2019
@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to api/.

🐱

Caused by: #7459 was synchronize by htuch.

see: more, trace.

Signed-off-by: Nick Smith <nick.a.smith@thalesesecurity.com>
@nickrmc83
Copy link
Contributor Author

Looks like envoy-linux and envoy-linux (bazel release) both failed due to a time with the same test: //test/extensions/transport_sockets/tls:ssl_socket_test. I don't think they are a result of these changes.

@nickrmc83 nickrmc83 closed this Sep 3, 2019
@nickrmc83 nickrmc83 reopened this Sep 3, 2019
@htuch
Copy link
Member

htuch commented Sep 3, 2019

@nickrmc83 sorry to do this, but I'm going to merge #8003 first, since it also mucks with api_build_system.bzl but is a much larger change, so we want to get it in ASAP now that it is LGTMed.

@htuch
Copy link
Member

htuch commented Sep 4, 2019

@nickrmc83 OK, #8003 is now merged; if you can merge master we can get this PR in as well, thanks again.

@htuch htuch added the waiting label Sep 4, 2019
@stale
Copy link

stale bot commented Sep 11, 2019

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!

@stale stale bot added the stale stalebot believes this issue/PR has not been touched recently label Sep 11, 2019
@stale stale bot removed the stale stalebot believes this issue/PR has not been touched recently label Sep 11, 2019
The metrics and trace APIs have external dependencies which are not yet
handled when generating CC stubs.

Signed-off-by: Nick A. Smith <nickrmc83@gmail.com>
@nickrmc83
Copy link
Contributor Author

@htuch this should be good to go.

Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@htuch htuch merged commit 41932e9 into envoyproxy:master Sep 16, 2019
danzh2010 pushed a commit to danzh2010/envoy that referenced this pull request Sep 24, 2019
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 <nickrmc83@gmail.com>
danzh2010 pushed a commit to danzh2010/envoy that referenced this pull request Oct 4, 2019
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 <nickrmc83@gmail.com>
danzh2010 pushed a commit to danzh2010/envoy that referenced this pull request Oct 4, 2019
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 <nickrmc83@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants