-
Couldn't load subscription status.
- Fork 81
Onboards to centralized resource access control for detectors and forecasters #1533
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
Onboards to centralized resource access control for detectors and forecasters #1533
Conversation
| Map<Recipient, Set<String>> recipients = Map.of(Recipient.BACKEND_ROLES, Set.copyOf(user.getBackendRoles())); | ||
| ShareWith shareWith = new ShareWith(Map.of(PLACE_HOLDER, new Recipients(recipients))); | ||
|
|
||
| resourceSharingClient.share(configId, configIndex, shareWith, ActionListener.wrap(resourceSharing -> { |
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.
we will no longer automatically share with backend roles upon config creation. Instead, users will now have to explicitly share the config with entities at certain access-levels. This will be done via explicit REST api calls or via dashboard component. Share API is being introduced here: opensearch-project/security#5459
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.
Few questions:
- Does this mean backend role filtering enabled setting doesn't do anything?
- If this is enabled we now no longer save check the backend role when doing operations?
- After creating detector/config they will need to call the share api if they want anyone but themselves to have access?
- will admin still have access to all configs/detectors
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.
After talking more offline, this is my current understanding:
- We are still gonna have some support of our backend role filtering but this new authz will be used if both flags are enabled, see: Onboards to centralized resource access control for detectors and forecasters #1533 (comment)
- we have the backend role as part of the user information but that isn't what dictates access to the detector, the access to the resource will be dictated based on permission granted in action group as part of security plugin
- yes for example: after creating a detector even if I have my own backend role of "HR" this isn't applied to the detector, if I want everyone with that backend role to be able to view the detector I need to call on share api to add backend role to the config ID for example for READ_ONLY or READ_WRITE
- Only super admin will have access, just getting * (all access admin) isn't enough to see all resources that are not shared.
| import org.opensearch.timeseries.model.DateRange; | ||
|
|
||
| public class JobRequest extends ActionRequest { | ||
| public class JobRequest extends ActionRequest implements DocRequest { |
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 how resource access requests are filtered for evaluation. Check out implementation here: https://github.com/opensearch-project/security/pull/5408/files#diff-5892c7b9dfd08da869c293e469b09654309be9994205ca939f0ce9e336d529de
| // detectorId will be null when this is a create request and so we don't need resource authz check | ||
| if (shouldEvaluateWithNewAuthz && !Strings.isNullOrEmpty(configId)) { | ||
| ResourceSharingClient resourceSharingClient = ResourceSharingClientAccessor.getInstance().getResourceSharingClient(); | ||
| resourceSharingClient.verifyAccess(configId, configIndex, ActionListener.wrap(isAuthorized -> { |
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.
with security plugin's lates change, access will be auto evaluated. Thus, we no longer need to explicitly call verifyAccess.
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.
Okay so from my understanding from offline conversation:
verifyAccess will look for a few things currently:
- global flag must be turned on along with ad flag
- request must be of DocRequest type
- any existing sharing info must have been migrated to the new model using /migrate API offered by security plugin
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
88d1bd0 to
1e2ee9c
Compare
|
CI will be unblocked once opensearch-project/security#5541 merges. |
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
|
|
||
| public AnomalyResultRequest(String adID, long start, long end) { | ||
| super(adID, start, end); | ||
| super(adID, ADIndex.CONFIG.getIndexName(), start, end); |
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.
why are we passing the AD config index here, is it cause we are only checking resource permission on config, we don't care for the other system indices right?
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 required for auto Resource Request evaluation. The base class ResultRequest extends DocRequest interface which require methods index() and id() to be implemented. These values are then used in security plugin to determine the resource id and index where resource resides, and use that information to perform evaluation.
| })); | ||
| assertTrue(inProgressLatch.await(10, TimeUnit.SECONDS)); | ||
| } | ||
|
|
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.
you removed this test, are we checking this somewhere else?
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 branch is no longer being tested here since AD no longer has knowledge of feature flag OPENSEARCH_RESOURCE_SHARING_ENABLED. It was added here specifically to cover that scenario.
if you look index IndexForecasterActionHandler.java, you will see that I've remove relevant code as well. We no longer automatically share the resource with backend_roles upon creation, with the new authz scheme. Users will be required to explicitly share the resource.
A share API is en-route to be added to Security plugin.
AD also has an option to add its own /share api however security is the ideal place as it avoids multiple implementations by different plugins to achieve same result.
| * @return true if the resource-sharing feature and filter-by is enabled, false otherwise. | ||
| */ | ||
| public static boolean shouldUseResourceAuthz(Settings settings) { | ||
| boolean filterByEnabled = AnomalyDetectorSettings.AD_FILTER_BY_BACKEND_ROLES.get(settings); |
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 new authz feature is still toggleable by the old setting of filter_by_backend_role. However, the ask from AD maintainers is whether this should still be kept as a switch for turning on the new authz scheme?
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.
yes I wanted to understand if we should be deprecating this switch already or not. From my understanding is for now:
global flag + ad flag -> new authz route
only ad flag -> current ad authz
no flag -> no sharing concept, default behavior where users can see other configs
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
…es in the rest tests Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
Signed-off-by: Darshit Chanpura <dchanp@amazon.com>
Description
This PR refactors changes introduced in #1400 to utilize auto-evaluation offered by security plugin.
This skips reliance on AD plugin to call verifyAccess
NOTE: Pipelines will fail until opensearch-project/security#5408 is merged.
Check List
--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.