[Discuss] When should plugins use system indices?

[peternied]

Describe the bug
Many plugins in the OpenSearch distribution use SystemIndexes for their plugin metadata, such as K-NN. However, OpenSearch Dashboards does not use a system index for its metadata store.

Upon inspecting the usage of system indexes in OpenSearch, it was found that they provide prioritization and thread pool isolation distinctions that are not available in "normal" indices.

The security plugin prevents modification of system indexes without mechanisms to grant access to users. While this may seem like a safety measure, it forces plugins to operate at a higher privilege level, which is less safe and does not provide protection from one plugin reading/modifying the contents of another plugin.

When should plugins use system indexes?

As OpenSearch builds up extensions should extensions have access to these system indexes?

[peternied]

We are looking at how to support system indexes for extensions in the security plugin and this came up. If there is strong direction either way it could impact how/if we build the feature. Would love feedback on this thread or the decision doc below

• [Question] How to Support System Indexes for Extensions? security#2530

[peternied]

@saratvemulapalli @minalsha @dbwiddis I think you might have strong options on this, love to get your thoughts.

[peternied]

@opensearch-project/plugins Do you have strong opinions on metadata storage for plugins, and them using system indexes?

[dblock]

I propose the following:

1. Access to system indices is sufficiently a special operation, that an extension can be allowed/disallowed to write to system indices separately from being allowed/disallowed to write to other indices.
2. Access to a system index is not different than an access to a regular index on top of (1), and can be allowed/disallowed index-by-index to all types of identities.

[saratvemulapalli]

Thanks for opening this up.
Plugins use system indices to make sure their metadata index is not modifiable by a user. System indices was the right solution which worked seamlessly for plugins.

System indices is a specific solution, for extensions we should let the extension define their permissions (which should include having admin access).
Extensions would definitely care:

• about protecting their metadata index from users
• a path forward for plugins moving to extensions
• access to system indices (may be a new security extension would need it)

[kaituo]

There are two types of system indices: one used by the security plugin, and another used by the OpenSearch core. The latter has higher prioritization and employs a dedicated threadpool. However, AD does not use the latter but relies on the system index provided by the security plugin.

I propose the following:

In the case of system indices from OpenSearch core, plugins may choose not to use them if their indices are less important than other user indices. (Context: opendistro-for-elasticsearch/anomaly-detection#394).

Regarding system indices from the security plugin, plugins use them to ensure that their metadata index cannot be modified by a user, as noted by @saratvemulapalli. Plugins may opt to use a normal user index if they wish to allow users to access the index for tasks such as plotting graphs on dashboards or enabling alerting.

[minalsha]

@peternied what are the next steps for this issue since it is a Discuss issue.

[peternied]

I think this discussion has concluded, in the plugin ecosystem system indices are the assumed place to store data, there is no appetite to removing/replacing this mechanism. Allowing these systems indices to be accessible in more context via specific permission [1] seems like the long term vision.

This topic might be revisited at a future time, but there are not outstanding questions. Thanks for the feedback everyone!

• [1] [META] System Indices access for Extensions security#2529