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

[Feature] Introduces Centralized Resource Access Control and Sharing #5016

Open
wants to merge 141 commits into
base: main
Choose a base branch
from

Conversation

DarshitChanpura
Copy link
Member

@DarshitChanpura DarshitChanpura commented Jan 10, 2025

Description

Introduces a new authorization mechanism to control access to resources defined by plugins.
There are 4 major components to this PR:

  1. Introduces an SPI that defines the contracts for a resource sharing plugin as well as Resource Access Control plugin.
  2. Introduces 4 new APIs that expose resource-sharing and access verification capabilities.
  3. Modifies DLS to implicitly check for resource-access for requesting user if incoming request is for a resource
  4. Adds a sample resource plugin with tests to demonstrate the usage of this new feature.
  5. Adds a feature flag to toggle the feature. Feature is enabled by default.
  • Category : New feature
  • Why these changes are required?
    • At present, plugins have implemented in-house authorization mechanisms for a lack of centralized framework. This PR introduces a centralized way to offload resource permissions check to security plugin. Plugins will leverage the java APIs introduced in core.

Issues Resolved

Testing

  • automated 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: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
@nibix
Copy link
Collaborator

nibix commented Jan 21, 2025

@DarshitChanpura

should the index be marked as hidden?

yes, any system index which is not directly relevant to the end user should be not visible by default to the user. Thus, it should be marked as hidden.

@DarshitChanpura
Copy link
Member Author

@DarshitChanpura

should the index be marked as hidden?

yes, any system index which is not directly relevant to the end user should be not visible by default to the user. Thus, it should be marked as hidden.

In this case the index is not technically directly relevant however when user shares the info or wants to check who has access to this resource. So I'm not sure if hidden still applies here.

@DarshitChanpura
Copy link
Member Author

I've opened a discussion issue to finalize the approach. #5062

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.

3 participants