[Question] Should resource-sharing information be stored on a dedicated index or on the resource index inside the documents?

[DarshitChanpura]

Please read original proposal: #4500 in-case you need context on the feature itself.

Proposal

With the recent changes in design approach of the Resource Sharing and Permissions feature, we've reached at a fork in the path where we must choose from 2 paths forward for storing resource-sharing data. Below, I've listed these two approaches in more detail:

Approach 1 : Dedicated index

This approach emphasizes storing resource sharing information on a dedicated index .opensearch-resource-sharing. A document will look something like:

{
    "_index": ".opensearch-resource-sharing",
    "_id": "ki95HkHK8H5Gm9O5T23i",
    "_score": 1.0,
    "_source": {
        "resource_id": "ej10HpQB9Y5Gm9L4T17p",
        "source_idx": ".sample-resource-plugin"
        "created_by": {
          "user": "darshit"
        },
        "share_with": {
          "restricted": {
             "users": ["craig", "derek"],
             "roles": [],
             "backend_roles": []
          }
        }
    }
}

This approach present a more simplistic path towards achieving resource-level access-control with some performance overhead.

1. Pros:
   1. This approach maintains separation of concerns .
   2. With this approach no additional protections need to be put in place to ensure that the resource-sharing related data is not unintentionally exposed to the user.
2. Cons:
   1. This approach requires a separate index call to this document when applying DLS which would add a performance overhead (significance yet to be determined)

Approach 2: Same Index

This approach emphasizes that the resource-sharing information will be stored in the resource document to keep it closer to the resource intended to have access-control. This would look something like:

{
    "_index": ".sample-resource-plugin",
    "_id": "ej10HpQB9Y5Gm9L4T17p",
    "_score": 1.0,
    "_source": {
        "name": "sample_test",
        "description": "Sample test resource for ResourcePlugin",
        "attributes": {
            "a": "b"
        },
        "created_by": {
          "user": "darshit"
        },
        "share_with": {
          "restricted": {
             "users": ["craig", "derek"],
             "roles": [],
             "backend_roles": []
          }
        }
    }
}

Although this approach looks similar to the current model where plugins store the user information in their own index, the biggest difference is that now security-plugin will be aware of this data and has control over it.

NOTE: With this approach, opensearch-project/OpenSearch#15778 becomes a requirement to enforce zero-trust policy and ensure that there is no unintended data-exposure.

1. Pros:
   1. No additional calls required when performing DLS to filter out non-accessible resources from the final result. Hence, no significant performance overhead.
2. Cons:
   1. This approach requires that proper barriers be put in place to prevent plugins from modifying the resource-sharing data.
      1. This should be only allowed for super-admin, security plugin and the owner of the resource.
   2. Proper scrubbers must be put in place so that users who are not the owners of a resource but still have access to it, must not see who else this resource is shared with.
      1. Resource owners, suepr-admin and security-plugin must still be able to view these details.

Intention

• To seek inputs on which approach should be selected.

[nibix]

One question: Is it clear that a resource maps always exactly to one document in an index?

[cwperks]

One question: Is it clear that a resource maps always exactly to one document in an index?

In order to use Resource Sharing + Authorization provided by the security plugin this assumption would need to hold true. In all of the cases analyzed in the default distribution where filter_by_backend_role is implemented, all of the resources correspond to a document in a system index.

That being said, there could be hierarchy to resources like the ML Commons use case where Model Groups are composed of model versions and access control is done on the Model Group level.

[nibix]

Also for alerting, there seems to be already a concept of sub-resources which inherit privileges from parent resources.

See for example alerting comments:

https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/kotlin/org/opensearch/alerting/transport/TransportIndexAlertingCommentAction.kt

Of course, it is possible to also implement access controls for these based on the new resource sharing model, quite similar to the present implementation.

But it shows the limitations of the resource = document model.

[cwperks]

Also for alerting, there seems to be already a concept of sub-resources which inherit privileges from parent resources.

See for example alerting comments:

https://github.com/opensearch-project/alerting/blob/main/alerting/src/main/kotlin/org/opensearch/alerting/transport/TransportIndexAlertingCommentAction.kt

Of course, it is possible to also implement access controls for these based on the new resource sharing model, quite similar to the present implementation.

But it shows the limitations of the resource = document model.

The PR that is open is solely about providing an off ramp for filter_by_backend_role which is a crude implementation of resource access control. Basically it filters what a user can see to what they are an owner of or if they share a backend role with the creator of the resource.

I think we'd certainly like to move to a different authorization model (in future versions of OpenSearch) where the owner of a resource can determine the access level when sharing their resource with another user in the system.

i.e. For a mental model I have been thinking about a Searchable Photo Album Plugin. In this plugin I can create an album and upload photos to the album. When I share my album with other users on the platform, I want to specify whether they have Read Only, Read + Comment, or Full Access on the album.

This model is not currently possible. Actions on resources are determined by what cluster_permissions a user has across all of their mapped roles.

[DarshitChanpura]

Citing security concerns, we've decided to store the information in a separate index. Thank you all for your inputs!