Write permissions in a FLS way

Hi,

I would like to create Search Guard users with restricted write permissions. The users are going to be used to push data from

shippers like Telegraf/Metricbeat. In Elasticsearch I am using one index for each shipper (e.g. metricbeat-DATE).

What I want to prevent is customers abusing Elasticsearch by shipping metrics with different server names:

example:
USER_A owns SERVER_A, which uses Search Guard SG_USER_A to ship metrics. USER_B owns SERVER_B,

which uses SG_USER_B to ship metrics. SERVER_A and SERVER_B are values of the server field in the metricbeat-DATE index.

What I don’t want is when SG_USER_A ships metrics with server=SERVER_B (and vice-versa). Any suggestions how to solve this?
I don’t think I can use FLS for writes, can I?

Best regards,

Jeroen

I don’t think that this can be done. Because if I understood your requirements correctly, you want to allow only certain values for a field, based on a user’s role. If this is the case then I am afraid we do not provide functionality for it.

···

On Thursday, October 18, 2018 at 10:38:10 AM UTC+2, Jeroen van Heugten wrote:

Hi,

I would like to create Search Guard users with restricted write permissions. The users are going to be used to push data from

shippers like Telegraf/Metricbeat. In Elasticsearch I am using one index for each shipper (e.g. metricbeat-DATE).

What I want to prevent is customers abusing Elasticsearch by shipping metrics with different server names:

example:
USER_A owns SERVER_A, which uses Search Guard SG_USER_A to ship metrics. USER_B owns SERVER_B,

which uses SG_USER_B to ship metrics. SERVER_A and SERVER_B are values of the server field in the metricbeat-DATE index.

What I don’t want is when SG_USER_A ships metrics with server=SERVER_B (and vice-versa). Any suggestions how to solve this?
I don’t think I can use FLS for writes, can I?

Best regards,

Jeroen

Thanks for the reply. Your assumption about the field values is correct. Are you aware of any other solution to ensure the authenticity of values shipped to ES?
Something like adding the used username to the fields would be fine as well (so I can check afterwards whether users submitted documents with illegal server names).

At the moment you can use Search Guard to filter documents and fields, but not to add fields or values. In other words, we never manipulate any documents being indexed. Having said that, we have a ticket in the backlog to add the currently logged in user to each indexed document. This is nearly exactly what you are looking for, but we did not get many requests for it so far from customers.

So until this is implemented (and we don’t have an ETA for it yet), I guess your only choice would be to use the write history of the compliance edition. With this, you can track changes (CRUD) to any document, and the emitted compliance event also contains the username.

However, I’m not sure that would help much with your use case since the username would not be present in the actual document, but in a separate document in another index.

If your users use the regular ES API, the only other way I can think of is to add a proxy in front of ES which would intercept the API calls, extracts the username, and then adds it to the documents. But - this is not really a feasible solution since you would need to handle bulk inserts as well.

···

On Monday, October 22, 2018 at 1:06:13 PM UTC+2, Jeroen van Heugten wrote:

Thanks for the reply. Your assumption about the field values is correct. Are you aware of any other solution to ensure the authenticity of values shipped to ES?
Something like adding the used username to the fields would be fine as well (so I can check afterwards whether users submitted documents with illegal server names).