-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
configure admin endpoint as a listener/http-filter (e.g. to secure via RBAC) #11367
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,9 @@ | ||
# DO NOT EDIT. This file is generated by tools/proto_sync.py. | ||
|
||
load("@envoy_api//bazel:api_build_system.bzl", "api_proto_package") | ||
|
||
licenses(["notice"]) # Apache 2 | ||
|
||
api_proto_package( | ||
deps = ["@com_github_cncf_udpa//udpa/annotations:pkg"], | ||
) |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
syntax = "proto3"; | ||
|
||
package envoy.extensions.filters.http.admin.v3; | ||
|
||
import "google/protobuf/wrappers.proto"; | ||
|
||
import "udpa/annotations/migrate.proto"; | ||
import "udpa/annotations/status.proto"; | ||
import "udpa/annotations/versioning.proto"; | ||
import "validate/validate.proto"; | ||
|
||
option java_package = "io.envoyproxy.envoy.extensions.filters.http.admin.v3"; | ||
option java_outer_classname = "AdminProto"; | ||
option java_multiple_files = true; | ||
option (udpa.annotations.file_status).package_version_status = ACTIVE; | ||
|
||
// [#protodoc-title: Admin] | ||
// Admin:ref:`configuration overview <config_http_filters_admin>`. | ||
// [#extension: envoy.filters.http.admin] | ||
|
||
message Admin { | ||
} |
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
One question I have on this API is whether we should have a
Listener
embedded in admin or somehow provide anadmin
filter that can be hooked into an arbitrary listener? I suspect what you have is the right thing given how admin works today, since it probably wants to be running on the main thread for thread safety with some of the data structures it serves. CC @envoyproxy/api-shepherdsHowever, by placing a listener here, it's providing a bigger "hole" than is needed. Listeners can be configured to do lots of things, e.g. act as a Thrift proxy, and only a narrow slice of this configuration will apply. Can you document how
Listener
is intended to be used when configured inside theAdmin
message?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.
My gut reaction is this config is right, but we should document the restrictions of the listener config which can be checked in code. I had discussed this offline with @cstrahan. So yeah +1 for documentation on the restrictions of the listener object and all of the check we should do in code on the config.
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 think I'd rather see it as a normal http filter attached to a normal listener. For things that must happen on the main thread, have the filter send a message back and forth for that work.
I'm worried that running arbitrary code on the main thread will expose issues because nobody intended all the non-admin filters or listener code to run on the main thread.
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 think this will likely end up being a really huge effort, though it's technically possible for sure.
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.
Another way of accomplishing the same thing is to post the entire request from the worker to the main thread, and post the response back to the worker. So leave everything done by the current admin endpoint on the main thread, and leave all the normal listener and filter-chain stuff on the worker thread.