Document Level Security version conflict error

[HeiDri]

Hi guys , i’m facing a problem using the document level security feature , so i created a role with cluster_composite_ops_ro permissions and * in index to access all indices and read and write permissions and in the document level security i wrote this

{
“bool”: {
“must”: { “match”: { “host.hostname”: “******”}}
}
}

when i try to log in using a user mapped tothis role it gives me this error

[data] [elasticsearch] [version_conflict_engine_exception]: [config:7.10.2]: version conflict, document already exists (current version [4])

i’m using the latest version of SG 49.0.0 with kibana 7.10.2

Any idea what am i doing wrong ?

thanks in advance

[nils]

Hello!

We probably need some more context here; thus, could you post your complete sg_roles.yml and a longer snippet from the logfile? Also, when writing “when I try to log in”, where are you logging in? Directly at Elasticsearch? In Kibana? Are you then unable to login, or are you able to login, but observe the error while being inside Kibana?

Generally, Document Level Security only affects reading operations. So, it sounds a bit weird that this is related to a version conflict, which can be only caused by writing operations.

[HeiDri]

i’ve created an internal user “user_only” which i mapped him to a read_only role which i created an has the permissions:

cluster permissions : cluster_composite_ops_ro
index : *
index permissions: read
dls : {“bool”: {“must”: {“match”: { “Carrier”: “Kibana Airlines”}}}}
Tenant: TEST

i’m using the sample data provided by kibana
when i say i’m not able to login i mean in kibana authentication page it gives the error message i mentioned before , and for the record elasticsearch is working fine.
when i remove the dls query everything is back to normal and i’m able to log in .
PS: the internal user is maped also to kibana_user role for a multitenancy purpose so he can see a few dashboards. maybe this has to do with the error mentioned before?

[nils]

My guess would be here that the index pattern * is a bit too broad.

Kibana stores its data in an own, private index. Thus, when logging into Kibana, you need to have permissions for this index. The Search Guard default configuration provides these permissions via the SGS_KIBANA_USER role.

When setting up DLS for all indices (*), this also affects the Kibana index. So, with this role, you are effectively restricting access to the Kibana index. As the Kibana index most probably does not have an attribute called Carrier, Kibana cannot read/write anything from this index. So, the login fails.

So, the solution would be using a more specific index pattern for the DLS rule.

[HeiDri]

thanks a lot for your help that was the problem , thanks a lot for all the amazing products you’re sharing with us