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

Subset of permissions check on creation #5012

Open
wants to merge 22 commits into
base: feature/api-tokens
Choose a base branch
from

Conversation

derek-ho
Copy link
Collaborator

@derek-ho derek-ho commented Jan 7, 2025

Description

This PR adds permission checks around API token creation, and cleans up misc. items from the feature branch, including authorizing API token endpoint properly and stashing the context in order to perform the API token refresh action without explicit permission to do so. This PR is dependent on #4992 to be merged first, and this PR only contains the following changes:

https://github.com/opensearch-project/security/pull/5012/files/aa506e78eb5699d2580e28d4bb0f0060971449e1..e13c055e063ae3e5ee40386a53155e5c65893b58

Issues Resolved

[List any issues this PR will resolve]

Is this a backport? If so, please add backport PR # and/or commits #, and remove backport-failed label from the original PR.

Do these changes introduce new permission(s) to be displayed in the static dropdown on the front-end? If so, please open a draft PR in the security dashboards plugin and link the draft PR here

Testing

[Please provide details of testing done: unit testing, integration testing and manual testing]

Check List

  • New functionality includes testing
  • New functionality has been documented
  • New Roles/Permissions have a corresponding security dashboards plugin PR
  • API changes companion pull request created
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Copy link

codecov bot commented Jan 7, 2025

Codecov Report

Attention: Patch coverage is 76.59574% with 22 lines in your changes missing coverage. Please review.

Project coverage is 71.23%. Comparing base (0edba23) to head (b6aa196).
Report is 33 commits behind head on feature/api-tokens.

Files with missing lines Patch % Lines
...arch/security/action/apitokens/ApiTokenAction.java 70.27% 19 Missing and 3 partials ⚠️
Additional details and impacted files

Impacted file tree graph

@@                  Coverage Diff                   @@
##           feature/api-tokens    #5012      +/-   ##
======================================================
- Coverage               71.46%   71.23%   -0.24%     
======================================================
  Files                     334      354      +20     
  Lines                   22552    23322     +770     
  Branches                 3590     3692     +102     
======================================================
+ Hits                    16117    16613     +496     
- Misses                   4642     4870     +228     
- Partials                 1793     1839      +46     
Files with missing lines Coverage Δ
.../opensearch/security/OpenSearchSecurityPlugin.java 83.92% <100.00%> (+0.36%) ⬆️
...ecurity/action/apitokens/ApiTokenIndexHandler.java 84.78% <100.00%> (ø)
.../security/action/apitokens/ApiTokenRepository.java 96.96% <ø> (ø)
...earch/security/auditlog/impl/AbstractAuditLog.java 76.88% <ø> (+0.15%) ⬆️
...rg/opensearch/security/dlic/rest/api/Endpoint.java 100.00% <100.00%> (ø)
...dlic/rest/api/RestApiAdminPrivilegesEvaluator.java 73.07% <100.00%> (+0.52%) ⬆️
...pensearch/security/http/ApiTokenAuthenticator.java 58.97% <ø> (ø)
...arch/security/action/apitokens/ApiTokenAction.java 40.10% <70.27%> (ø)

... and 12 files with indirect coverage changes

Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
Signed-off-by: Derek Ho <[email protected]>
@derek-ho derek-ho marked this pull request as ready for review January 10, 2025 17:59
@derek-ho derek-ho self-assigned this Jan 10, 2025
* Validates that the user has the required permissions to create an API token (must be a subset of their own permissions)
* */
@SuppressWarnings("unchecked")
void validateUserPermissions(List<String> clusterPermissions, List<ApiToken.IndexPermission> indexPermissions) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

So, the token they are requesting is validated to be a subset of the permissions available to them in roles.yml, right?

What is supposed to happen if the permissions in roles.yml are later changed, especially if they are reduced?

// Early return conditions
if (roles.isEmpty()) {
throw new OpenSearchException("User does not have any roles");
} else if (roles.contains("all_access")) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this assumption safe?

List<String> roleIndexPerms = indexPermission.getAllowed_actions();

// Check if this role's pattern covers the requested pattern
if (WildcardMatcher.from(rolePatterns).test(requestedPattern)) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Assume that I have a role with the index_pattern /index_[0-9]+/. How can a requestedPattern look like that replicates this pattern?

At the moment, I have doubts that simple pattern matching can be used to support the full pattern semantics.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This also does not cover alias semantics.

return DynamicConfigFactory.addStatics(loaded);
}

protected void authorizeSecurityAccess(RestRequest request) throws IOException {
Copy link
Collaborator

Choose a reason for hiding this comment

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

What do you think about having a dedicated transport action backing the REST action? Then, one would get access control out of the box without needing explicit checks within the action code.

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.

2 participants