[DRAFT] [Feature]Introduces ability to control access to and share resources #16030
Conversation
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
Signed-off-by: Darshit Chanpura <[email protected]>
…urceService 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]>
DarshitChanpura
requested review from
anasalkouz,
andrross,
ashking94,
Bukhtawar,
CEHENKLE,
dblock,
dbwiddis,
gbbafna,
jainankitk,
kotwanikunal,
linuxpi,
mch2,
msfroh,
nknize and
owaiskazi19
as code owners
DarshitChanpura
requested review from
reta,
Rishikesh1159,
sachinpkale,
saratvemulapalli,
shwetathareja,
sohami and
VachaShah
as code owners
|
❌ Gradle check result for 7e7cd0a: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
@reta @jainankitk Would love to get some initial feedback on this PR. This is still work-in-progress. |
| */ | ||
| @Override | ||
| public Map<String, List<String>> listAccessibleResources() { | ||
| return Map.of(); |
There was a problem hiding this comment.
In NoOp implementation, wouldn't a plugin expect to be able to list all? Why the return type Map<String, List<String>>? Can this be made more generic and let the plugin that defines the Resource to be able to serialize and deserialize what is stored in a resource index?
| * @return empty list | ||
| */ | ||
| @Override | ||
| public List<String> listAccessibleResourcesForPlugin(String systemIndexName) { |
There was a problem hiding this comment.
I think any instance of systemIndex should be renamed to resourceIndex. A resourceIndex is a system index, but it would specifically be for plugins that want to have this resource-sharing ability.
| */ | ||
| public class ShareWith implements ToXContentFragment { | ||
|
|
||
| private List<String> users; |
There was a problem hiding this comment.
I'm hesitant to introduce notions of roles, backend roles or user into the core. I'm wondering if Security can provide a class similar to this to plugins (similar to SPI model from JS), but not have plugins formally extending the security plugin. If a plugin extends another plugin then it means that the other plugin must be installed in a cluster before the plugin that depends on another can be installed.
With resource sharing, if the security plugin is not installed then all users will have full access to all plugin resources.
With the security plugin installed it can enforce authz on plugin resources using this new mechanism.
| * compatible open source license. | ||
| */ | ||
|
|
||
| /* |
There was a problem hiding this comment.
The License below can be removed
| * The index where resource meta-data is stored | ||
| * @return the name of the parent index where resource meta-data is stored | ||
| */ | ||
| String getResourceIndex(); |
There was a problem hiding this comment.
Can a plugin define multiple types of resources that can be shared?
i.e. In a hypothetical Searchable Photos plugin, would it be able to do resource sharing on both the Album level and Photo level?
|
|
||
| /** | ||
| * This class contains information about whom a resource is shared with. | ||
| * It could be a user-name, a role or a backend_role. |
There was a problem hiding this comment.
Is it really necessary to support all three criteria (user name, roles, backend roles)? Especially back end roles can vary between auth backend (e.g. users authenticated via LDAP might have different backend roles than users authenticated via OIDC).
Such disparities can lead to confusion.
Who is supposed to specify these criteria when?
There was a problem hiding this comment.
Unfortunately, backend roles is already in place amongst plugins that implement custom resource authz.
Its already in place in:
- ML Commons
- Flow Framework
- Anomaly Detection
- Alerting
I think there may be others as well (possibly Reporting?).
Backend roles would need to be supported in order for those plugins to adopt the mechanism provided by security.
There was a problem hiding this comment.
Ah, so this has the goal of a seamless transition from the older methods used in these different plugins?
Still, from a UX point of view, having too many options for a single thing is not optimal. It requires users to make a choice which is the optimal option. Proper information on how to make the right choice might be hard to find or might even not exist.
This is actually demonstrated by the broad range of artifacts which require backend roles in their configuration.
Thus, maybe the backend role option should be marked as deprecated? Or, maybe the docs should be clearer on how to use the roles?
DarshitChanpura
force-pushed
the
resource-permissions
branch
from
c8d678d
to
d8710cc
Compare
Signed-off-by: Darshit Chanpura <[email protected]>
DarshitChanpura
force-pushed
the
resource-permissions
branch
from
d8710cc
to
23fcfba
Compare
Signed-off-by: Darshit Chanpura <[email protected]>
|
❌ Gradle check result for fba48ab: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
Work in Progress.
companion PR: opensearch-project/security#4746
Description
This PR introduces a new capability to enable access-control and sharing of resources. This PR introduces:
At present, plugins have implemented in-house authorization mechanisms to control access to their resources. This framework enables capability to have a centralized resource-authorization framework.
Please review feature proposal here that discusses the problem-statement and design approach. opensearch-project/security#4500
Plugins will leverage the APIs introduced here to check user access to resources.
To-do items:
Documentation website will follow.
Related Issues
Check List
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.