[Resource Access Control] [Part2] Introduces a client for Resource Access Control and adds concrete implementation for resource access control #5194

DarshitChanpura · 2025-03-20T18:03:21Z

#5185 must be merged before merging this.

#5016 is being broken down into smaller pieces. This is part 2.

Description

Introduces a client to be consumed by plugins, and adds concrete implementation of ResourceAccessControl.

There are 4 java APIs as well as 4 REST APIs introduced as part of this PR. Plugins will leverage the client to call the java APIs to implement resource access control.

Refer to the RESOURCE_ACCESS_CONTROL_FOR_PLUGINS.md file to understand in-depth implementation of this feature.

Issues Resolved

Resolves [Proposal] Resource Permissions and Sharing #4500

Testing

automated tests + manual tests

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]>

…ntrol implementation in common package Signed-off-by: Darshit Chanpura <[email protected]>

Signed-off-by: Darshit Chanpura <[email protected]>

nibix

Thanks for this interesting PR @DarshitChanpura !

I have added a couple of comments and questions. As I went through the code linearly, I also commented both on conceptual things and code level things (which I mostly marked with Nit:). I would recommend that you first have a look on conceptual things ... we can talk about the Nit stuff later.

If you want, we can also schedule a conversation at some point in time.

nibix · 2025-03-21T06:09:20Z

RESOURCE_ACCESS_CONTROL_FOR_PLUGINS.md

+  POST /_plugins/_security/resources/verify_access
+  ```
+- **Description:**
+  Verifies whether the current user has access to a specified resource within the given index and scopes.


Could you elaborate a bit on the use case of this endpoint?

Normally, I can test whether I have access to any RESTful resource by just doing a GET on the resource itself and see if I get a 200 or a 403 status in return.

This is intended to be used by plugins via a Java client (or similar) as an alternatively to nodeClient provided by the opensearch-security-client package.

It serves the purpose you described but in a boolean form. As there is no way of blocking access to individual resource, a GET of a resource (or any) will always result in 200 if you have access to the transport action (cluster:..). We are trying to prevent this by adding verification for individual resource.

nibix · 2025-03-21T06:12:22Z

RESOURCE_ACCESS_CONTROL_FOR_PLUGINS.md

+```json
+{
+  "resource_id": "my-resource",
+  "resource_index": "resource-index",


Exposing the resource-index feels like exposing an implementation detail to me. Am I right that normal users won't be able to access the resource index directly? Then, it should be not visible to them.

Can't we use the resource type here?

(same holds for the other REST endpoints)

we can obfuscate it from the API response. However, in an actual resource-sharing record in the index this information is required. Even if the index name is exposed, a regular user will not be able to access it since we are requiring it to be a system index.

nibix · 2025-03-21T06:14:58Z

RESOURCE_ACCESS_CONTROL_FOR_PLUGINS.md

+### **3. Revoke Access**
+- **Endpoint:**
+  ```
+  POST /_plugins/_security/resources/revoke
+  ```
+- **Description:**
+  Revokes access to a resource for specific users, roles, or backend roles under certain scopes.


Am I right in the assumption that only the resource owner is allowed to revoke resource access? This probably should be made explicit in the description.

What happens if I revoke a READ_WRITE scope from a user who has only a READ scope?

For now, yes. Only users or admin-certificates can update the resource + its access and delete the resource.

nibix · 2025-03-21T06:20:02Z

client/src/main/java/org/opensearch/security/client/resources/ResourceSharingNodeClient.java

+        if (isSecurityDisabled || !resourceSharingEnabled) {
+            String message = isSecurityDisabled ? "Security Plugin is disabled." : "ShareableResource Access Control feature is disabled.";
+
+            log.warn("{} {}", message, "Access to resource is automatically granted");


Nit: Do we need to log a warning in each case?

If users have disabled security or resource sharing they will have deliberately done so (it's difficult to do it accidentally). Logging a warning for each call seems to be quite verbose.

I found it helpful while debugging hence added it. If consensus is to remove then I can remove it.

src/main/java/org/opensearch/security/OpenSearchSecurityPlugin.java

src/main/java/org/opensearch/security/user/User.java

nibix · 2025-03-21T08:44:54Z

src/main/java/org/opensearch/security/resources/rest/ResourceAccessRequest.java

+    public enum Operation {
+        LIST,
+        SHARE,
+        REVOKE,
+        VERIFY
+    }


Nit: The whole action combines four operations into one. This leads to a couple of oddities, like the Object response attr in ResourceAccessResponse. IMHO, it would make sense to divide this into four actions.

I had it separated out which results in quite a few redundant files. Let me know if you still think it would be best to split it.

src/main/java/org/opensearch/security/dlic/rest/support/Utils.java

nibix · 2025-03-21T10:05:49Z

RESOURCE_ACCESS_CONTROL_FOR_PLUGINS.md

+### **Common Scopes for Plugins to declare**
+| Scope        | Description                                         |
+|-------------|-----------------------------------------------------|
+| `PUBLIC`    | The resource is accessible to all users.            |
+| `READ_ONLY` | Users can view but not modify the resource.         |
+| `READ_WRITE` | Users can view and modify the resource.             |
+
+By default, all shareableResources are private and only visible to the owner and super-admins. Resources become accessible to others only when explicitly shared.
+
+SPI provides you an interface, with two default scopes `PUBLIC` and `READ_ONLY`, which can be extended to introduce more plugin-specific values.


The table lists a scope READ_WRITE which is not mentioned in any other place. Is this on purpose?

Additionally, could you give an example for a more evolved set of scopes a real-world plugin might use?

I am asking because I am a bit lost what scopes can be. To a certain extent because PUBLIC and READ_ONLY seem to refer to different dimensions in my perception. PUBLIC refers to group of users, while READ_ONLY refers to an allowed action.

these names currently serve semantic purpose only. The context and meaning of these scopes is left to the plugins to determine how they would like to define and utilize them. However, before we proceed on this discussion, let finalize the part forward for scopes as there seems to be confusion around it: #5185 (comment)

nibix · 2025-03-21T10:07:49Z

RESOURCE_ACCESS_CONTROL_FOR_PLUGINS.md

+#### **Example: PUBLIC Scoped Document**
+If a resource is intended to be publicly accessible, it must be shared using the following structure:
+
+```json
+{
+    "share_with": {
+        "public": {
+            "backend_roles": ["*"],
+            "roles": ["*"],
+            "users": ["*"]
+        }
+    }
+}
+```
+
+In this structure:
+- `"backend_roles": ["*"]` → Grants access to all backend roles.
+- `"roles": ["*"]` → Grants access to all roles.
+- `"users": ["*"]` → Grants access to all users.
+
+**This ensures that the resource is accessible to everyone.**


Could you elaborate what's here the difference to the following one:

{ "share_with": { "read_only": { "backend_roles": ["*"], "roles": ["*"], "users": ["*"] } } }

the scope names are only semantic atm. This will in future be mapped to action groups. The discussion can be found under this thread: #5185 (comment)

Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura requested review from cwperks, derek-ho, nibix, peternied, RyanL1997, reta and willyborankin as code owners March 20, 2025 18:03

DarshitChanpura added 7 commits March 20, 2025 14:30

Introduces resource sharing and access control SPI

2246d91

Signed-off-by: Darshit Chanpura <[email protected]>

Introduces a resource sharing client and completes resource access co…

c8245dc

…ntrol implementation in common package Signed-off-by: Darshit Chanpura <[email protected]>

Updates client to handle security disabled scenario

7631bd0

Signed-off-by: Darshit Chanpura <[email protected]>

Updates build.gradle files and jarhell references

84b2a21

Signed-off-by: Darshit Chanpura <[email protected]>

Disables jar for common

3d9c9c1

Signed-off-by: Darshit Chanpura <[email protected]>

Removes common package and refactors classes

f167091

Signed-off-by: Darshit Chanpura <[email protected]>

Conforms to SPI file name changes and removes spi package

89d3a63

Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura force-pushed the resource-sharing-client branch from 33c2dc4 to 89d3a63 Compare March 20, 2025 18:33

DarshitChanpura added 2 commits March 20, 2025 16:24

Updates plugin dev doc

643e44f

Signed-off-by: Darshit Chanpura <[email protected]>

Fixes CI

52f4ac5

Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura force-pushed the resource-sharing-client branch from 597172b to 52f4ac5 Compare March 20, 2025 20:38

nibix reviewed Mar 21, 2025

View reviewed changes

nibix mentioned this pull request Mar 21, 2025

[Resource Access Control] [Part1] Introduces SPI for resource access control #5185

Open

1 task

Updates exception types in client and root project

e05ae8a

Signed-off-by: Darshit Chanpura <[email protected]>

DarshitChanpura force-pushed the resource-sharing-client branch from e38b67e to e05ae8a Compare March 21, 2025 22:26

Addresses PR comments

c0c9f9b

Signed-off-by: Darshit Chanpura <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Resource Access Control] [Part2] Introduces a client for Resource Access Control and adds concrete implementation for resource access control #5194

[Resource Access Control] [Part2] Introduces a client for Resource Access Control and adds concrete implementation for resource access control #5194

DarshitChanpura commented Mar 20, 2025 •

edited

Loading

nibix left a comment

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025

nibix Mar 21, 2025

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025

nibix Mar 21, 2025

DarshitChanpura Mar 21, 2025 •

edited

Loading

[Resource Access Control] [Part2] Introduces a client for Resource Access Control and adds concrete implementation for resource access control #5194

Are you sure you want to change the base?

[Resource Access Control] [Part2] Introduces a client for Resource Access Control and adds concrete implementation for resource access control #5194

Conversation

DarshitChanpura commented Mar 20, 2025 • edited Loading

Description

Issues Resolved

Testing

Check List

nibix left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DarshitChanpura Mar 21, 2025 • edited Loading

Choose a reason for hiding this comment

DarshitChanpura commented Mar 20, 2025 •

edited

Loading

DarshitChanpura Mar 21, 2025 •

edited

Loading