kbs/admin: modularize admin authentication and authorization#2
Open
Xynnn007 wants to merge 5 commits intofitzthum:admin-3from
Open
kbs/admin: modularize admin authentication and authorization#2Xynnn007 wants to merge 5 commits intofitzthum:admin-3from
Xynnn007 wants to merge 5 commits intofitzthum:admin-3from
Conversation
Introduce the admin role configuration at the admin level (rather than the admin backend level). This way, we don't need to duplicate the admin logic for each backend. An admin role matches a particular admin id to a regex. The regex controls which endpoints are allowed. In the future, we could make both fiels regular expressions to more flexibly match different admin ids. If no roles are specified, all admin will have access to all endpoints. This provides backwards compatibility. Signed-off-by: Tobin Feldman-Fitzthum <tfeldmanfitz@nvidia.com>
Add unit tests for admin roles. Try creating the Admin struct with a few different configs, and validate some requests. I find putting a bunch of JSON into the rstest macro to be hard to read, so these tests just do everything in Rust. Signed-off-by: Tobin Feldman-Fitzthum <tfeldmanfitz@nvidia.com>
Quick fixup of the integration test. An integration test using roles will follow in a future PR. Signed-off-by: Tobin Feldman-Fitzthum <tfeldmanfitz@nvidia.com>
Update the KBS config doc to include the structure of the admin roles configuration and a description of how admin roles work. Signed-off-by: Tobin Feldman-Fitzthum <tfeldmanfitz@nvidia.com>
Refactor the admin module from simple monolithic implementations to a modular architecture that separates token verification from authorization decisions. Key changes: - Split admin functionality into two independent modules: * token_verifier: Handles token parsing and verification (BearerJwt) * authorization: Handles access control decisions (RegexAcl) - Replace simple backend types (allow_all, deny_all, simple) with trait-based architecture for better extensibility - Update AdminConfig to use "mode" enum (InsecureAllowAll, DenyAll, Enforce) instead of "type" for clearer semantics - Enforce mode requires both token_verifier and authorizer configuration - Improve error handling with detailed reason messages in AdminAccessDenied This refactoring improves code organization, maintainability, and makes it easier to add new token verifiers or authorization strategies in the future. Signed-off-by: Xynnn007 <xynnn@linux.alibaba.com>
fitzthum
force-pushed
the
admin-3
branch
4 times, most recently
from
0168e00 to
093fa66
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refactor the admin module from simple monolithic implementations to a modular architecture that separates token verification from authorization decisions.
Key changes:
This refactoring improves code organization, maintainability, and makes it easier to add new token verifiers or authorization strategies in the future.
Note that this PR does not handle the following things