System indices, what are they for and how safe is it to give access to them

Security
1

Hi, I am using the docker version of opensearch and with it comes some default configuration files and in one of them you list a lot of system indices.

plugins.security.system_indices.indices: [“.opendistro-alerting-config”, “.opendistro-alerting-alert*”, “.opendistro-anomaly-results*”, “.opendistro-anomaly-detector*”, “.opendistro-anomaly-checkpoints”, “.opendistro-anomaly-detection-state”, “.opendistro-reports-", ".opendistro-notifications-”, “.opendistro-notebooks”, “.opendistro-asynchronous-search-response*”]

I have been searching high and low in order to find what each of these are for, how safe it is to give access to them for a normal user (like you need create rights on .opendistro-reports-* in order to create reports and download them. But could you by having that access get access to data you shouldn’t have, say someone else create a report from other indices, will those be stored there?

What do all of the other ones do, the documentation is quite lacking when it comes to these security parts unfortunately. Can anyone shed some light on them? Do you need them all specified, I saw you don’t need them according to the documentation but will that mean you loose that functionality or will it be stored in .kibana_* instead?

Grateful for any insight into this labyrinth :smiley:

Br
Jan

2

@Jan
These are system indices, no user should have access to view these. The config is created behind the scenes. The permissions are responsible for granting access for setting up alerts etc. But not direct access to the system indices.

.opendistro_security is a clear example of this, it is by default a protected index, not even admin user can view the data. All the configuration is done via API, UI or directly by updating yaml files.

So in short, no, no access is needed for any user. Hope this clears it up

3

Thanks, but for something as common as reports you need to set the following cluster rights:

Selection_188

We got the following error creating a report as a user:

,“audit_request_privilege”:“indices:admin/create”,“audit_request_remote_address”:“192.168.32.4”,“audit_trace_indices”:[“.opendistro-reports-instances”

So we added that by tracing a report creation from admin, and then today we kind of figured out that you had to just have done a report as admin so this indices was created since the user isn’t allowed to create anything but kibana* ones. I guess a general creation of indices could work to mitigate this, but can that cause any other issues?

4

@Jan You can give “indices:admin/create” to only the specific index, in case of reporting “.opendistro-reports-*”. There shouldn’t be any issues with this approach. Or if users are ok to have ability to create indices, this can be applied to all indices.

This is different to having direct access to the system index, which is why it’s included in plugins.security.system_indices.indices. Hope this helps

5

That was pretty much as I expected, just wanted to be sure :slight_smile: better safe than sorry as they say :slight_smile:
Thanks a lot for the help

Br
Jan