Grant write permissions to documents on document and field level

Security
1

Hello everyone,

in our system we want to administrate users with the security plugin and give them access to certain documents in the indices only.
With “give access to” we mean administrate the visibility (search/reading rights) and the ability to change the documents or even certain fields (update/index).
Administrating reading/searching rights is straight forward and possible with the document + field level security.
We expected that the same applies to write and update permissions but we face the following issues:

  1. Apparently it is not possible to update documents if the user who sends requests to the _update api is limited by a role that applies DLS to the respective index.
  2. In order to allow a user, that is assigned to a role that regulates permissions with DLS, to index documents /_doc/, the cluster permission indices:data/write/bulk needs to be granted. But this is incompatible with our requirement to restrict the write access of the user to certain documents or even fields of documents (the same as Cluster-permission indices:data/write/bulk needed for adding data?- implications?). With this permission the user can change any documents and create new documents

Do you see a possibility to achieve what is described above with the opensearch security plugin?
We have the possibility to create separate indices that are synced with the “read-only-indices” and contain only contain documents with the fields that we want the user to be able to change. Then, we could give write access to these separate indices only. But strictly speaking this is not what we want since we still can’t control the write permissions on document level (a user still can change every document in the separate indices).

Maybe you have some ideas :slight_smile: Thank you very much for your help in advance!!

2

@AdmireDirac
I have just tested with opensearch 1.3.2 and the “indices:data/write/bulk” is not required to index and read the document.

In my case the custom role looks like this (this is only for read):

testRole2:
  reserved: false
  hidden: false
  cluster_permissions: []
  index_permissions:
  - index_patterns:
    - "something*"
    fls: []
    dls: '{"bool": {"filter": [{"term": { "something": "new" }}]}}'
    masked_fields: []
    allowed_actions:
    - "read"
  tenant_permissions: []
  static: false

If you add write to the actions list, the user will be able to create new documents. The update, however, is not supported in this case, as per the error message:
Update is not supported when FLS or DLS or Fieldmasking is activated

Therefore this should work if you are using the approach of coping indices with only the allowed fields.

3

AFAIK you should never mix DLS/FLS and write for the same user: this can cause issues, e.g. when a user writes a document which will afterwards no longer be matched by the DLS and accordingly will no longer be visible to the user.

however, this is not documented in the OpenSearch docs (might be something to extend?). Search Guard has something in their docs: Search Guard document-level security basics | Security for Elasticsearch | Search Guard

4

@Anthony
Thank you for your reply. Your observations are similar to ours then. At least we know that we didn’t configure anything wrong.

@ralph
Thank you aswell. We are aware of the issues that might occur but we thought that is was open to the administrator to make sure that they don’t occur.
We tried the search guard open that is mentioned in the linked article but this didn’t show an effect. Is opensearch actually using search guard?

To everyone reading this who wants to know with which solution we are proceeding
Luckily we started from elasticsearch and didn’t want to pay for the features that allow authentication with LDAP or AD. Thus, we implemented a flask proxy that did just that with kerberos (reverse proxy). When switching to opensearch we first thought that our implementation was obsolete since the required freature is free in opensearch but we kept if for you-never-know-reasons.
Now, we plan to do the following. We provide our own update API that is handled by the reverse proxy:
Permissions are still administrated via the opensearch mechanism. There are a certain set of fields that a user can change in general and specifically only if the admin granted write permissions. If the reverse proxy receives a request over the custom update API, rights for the requesting user are verfied and an opensearch-update-request is performed by the reverse proxy with an internal user that is only accessible by the reverse proxy. This internal user has all necessary permissions to perform such an update request and the logic in the custom update API makes sure that no conflicts arise from the update.