[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?