-
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
auth: new api auth implementation #36968
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: wangbaiping/wbpcode <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
message Credential { | ||
// The value of the unique API key. | ||
string api_key = 1 [(validate.rules).string = {min_len: 1}]; | ||
|
||
// The unique id or identity that used to identify the client or consumer. | ||
string client_id = 2 [(validate.rules).string = {min_len: 1}]; | ||
} | ||
|
||
message Credentials { | ||
repeated Credential entries = 1; | ||
} | ||
|
||
// Api credentials used to authenticate the clients. | ||
Credentials credentials = 1 [(udpa.annotations.sensitive) = true]; |
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.
The api key credenticals has clear structure. It would be better to use a typed message rather than DataSource.
It's OK to change the API because the #36709 was just merged.
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.
FWIW, this implies that only an xDS-update will change the credentials.
If that is the intended behavior, that's fine by me, although I can see some (not huge) benefits of using DataSource (e.g., fine-granularity of credentials updates, and using env-vars).
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.
@adisuissa Yeah. I know. I prefer the explicitly defined structures rather than plain string or bytes and I think the xDS should be the first way to update the configuration.
And specific to the DataSource advantages, there are two possible compromised ways:
- Use the DataSource as config field type but require it's content to keep the structure of the
Crendentials
. We can load it by theloadFromJsonString
directly to aCrendentials
proto type. - Add a new DataSource config field in the
Credentials
future if some users require env/file support. By this way, we can use both xDS or local file/env to configure this filter.
Both are ok to me (and a inclided to the second way), which one would you prefer?
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
cc @envoyproxy/api-shepherds |
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
@@ -172,6 +172,7 @@ paths: | |||
- source/extensions/compression/zstd/common/dictionary_manager.h | |||
- source/extensions/filters/http/adaptive_concurrency/controller | |||
- source/extensions/filters/http/admission_control | |||
- source/extensions/filters/http/api_key_auth |
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 necessary because the ExceptionFreeFactoryBase
cannot handle the case where the route specific configuration loading will throw the exception.
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
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!
Left a few high-level comments about the API.
I'll review the rest of the code once the API is more stable.
message Credential { | ||
// The value of the unique API key. | ||
string api_key = 1 [(validate.rules).string = {min_len: 1}]; | ||
|
||
// The unique id or identity that used to identify the client or consumer. | ||
string client_id = 2 [(validate.rules).string = {min_len: 1}]; | ||
} | ||
|
||
message Credentials { | ||
repeated Credential entries = 1; | ||
} | ||
|
||
// Api credentials used to authenticate the clients. | ||
Credentials credentials = 1 [(udpa.annotations.sensitive) = true]; |
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.
FWIW, this implies that only an xDS-update will change the credentials.
If that is the intended behavior, that's fine by me, although I can see some (not huge) benefits of using DataSource (e.g., fine-granularity of credentials updates, and using env-vars).
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
docs/root/configuration/http/http_filters/api_key_auth_filter.rst
Outdated
Show resolved
Hide resolved
envoy.filters.http.api_key_auth: | ||
categories: | ||
- envoy.filters.http | ||
security_posture: robust_to_untrusted_downstream |
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 will probably need a signoff from the security group.
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.
cc @envoyproxy/security-team
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
docs/root/configuration/http/http_filters/api_key_auth_filter.rst
Outdated
Show resolved
Hide resolved
credentials: | ||
entries: | ||
- api_key: one_key | ||
client_id: one_client |
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.
Probably a dumb question: where does the "one_client" value coming from in the data-plane (how it the "related client" defined)?
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.
Probably a dumb question: where does the "one_client" value coming from in the data-plane (how it the "related client" defined)?
It's hard to answer this quesion. the client_id
is an identity that related to the key
. It could be anything that could be used to identify a client/app or a group of clients/apps.
For a specific example, the gateway production may provides the ability to manage the credentials. And that credentials management module may allow users to create or define the client
or consumer
, and then, users could create some keys that related to the client
/consumer
.
In conclusion, it depends on the abstraction of the gateway production.
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
/docs |
Docs for this Pull Request will be rendered here: https://storage.googleapis.com/envoy-pr/36968/docs/index.html The docs are (re-)rendered each time the CI |
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
/retest |
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
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!
Overall LGTM, mostly left minor comments.
This is now ready for a senior-maintainer pass (preferably someone with the domain background).
@@ -28,27 +26,84 @@ option (xds.annotations.v3.file_status).work_in_progress = true; | |||
// .. code-block:: yaml | |||
// | |||
// authentication_header: "X-API-KEY" |
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.
Where is the authentication_header
config field defined?
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.
sorry, this should be updated.
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
api/envoy/extensions/filters/http/api_key_auth/v3/api_key_auth.proto
Outdated
Show resolved
Hide resolved
absl::variant<Http::LowerCaseString, std::string> source_{""}; | ||
bool query_source_{}; |
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 a code smell that is due to the use of absl::variant over using OO polymorphism.
….proto Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
….proto Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Signed-off-by: code <wbphub@gmail.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Hi, @yanavlasov could you take a look at this PR to give second pass when you get some free time. I saw you are maintainer of jwt and rbac, so should have lots of background knowledge about the authentication/authorizaton. |
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Commit Message: auth: new api auth implementation
Additional Description:
To close #34877
Risk Level: low. New extension.
Testing: unit, integration.
Docs Changes: added.
Release Notes: added.
Platform Specific Features: n/a.