[Enhancement] Use System index registry from the core to determine if a request matches system indices

[cwperks]

Currently, the security plugin uses an opensearch setting to track the list of system index patterns in the cluster. To enable system index protection requires a cluster admin to configure the following settings:

plugins.security.system_indices.enabled: true
plugins.security.system_indices.indices: [".apm-custom-link", ".opensearch_dashboards", ".apm-agent-configuration", ".opensearch_dashboards_*", ".reporting-*", ".plugins-ml-config", ".plugins-ml-connector", ".plugins-ml-model-group", ".plugins-ml-model", ".plugins-ml-task", ".plugins-ml-conversation-meta", ".plugins-ml-conversation-interactions", ".opendistro-alerting-config", ".opendistro-alerting-alert*", ".opendistro-anomaly-results*", ".opendistro-anomaly-detector*", ".opendistro-anomaly-checkpoints", ".opendistro-anomaly-detection-state", ".opendistro-reports-*", ".opensearch-notifications-*", ".opensearch-notebooks", ".opensearch-observability", ".ql-datasources", ".opendistro-asynchronous-search-response*", ".replication-metadata-store", ".opensearch-knn-models", ".geospatial-ip2geo-data*"]

For concrete indices matching these patterns, the security plugin gives special protections that forbid regular users (including admin) from performing operations on these indices like writing to the index or deleting the index. The integrity of system indices is important for cluster operations and these indices are not meant to be meddled with by regular users.

OpenSearch core provides an extension point called SystemIndexPlugin that is intended for plugins that define system index patterns. In effect, this extension point creates a registry of system indices that is known to the core. Only a subset of default plugins that create system indices currently use the extension point.

Currently, the security plugin does not utilize this registry to determine if an incoming request contains indices that match system indices and instead relies on the configured setting.

The security plugin should take advantage of the system index registry in core to determine if a request matches system indices. This will have an advantage of plugin teams not needing to create an additional PR to the security plugin, but will also have a formal mapping from \<plugin> -> Set\<String> systemIndexPatterns which will help towards https://github.com/opensearch-project/security/issues/4439 which is seeking to provide better system index protection in the plugin ecosystem.

[cwperks]

A couple of questions to look into further:

• Do all nodes of the cluster need to have the same set of plugins installed?
• If some nodes only have a subset of plugins installed, then how can all nodes be aware of all system index patterns that have been registered?

[DarshitChanpura]

• Do all nodes of the cluster need to have the same set of plugins installed?
• If some nodes only have a subset of plugins installed, then how can all nodes be aware of all system index patterns that have been registered?

Is there an efficient way to form a "union" set of plugin's system indices across all nodes?

[shikharj05]

Do all nodes of the cluster need to have the same set of plugins installed?

I don't think this is a requirement today.

If some nodes only have a subset of plugins installed, then how can all nodes be aware of all system index patterns that have been registered?

If a plugin registering a system index is not present on one of the nodes, the index won't be treated as system index on that node and hence this could lead to bad/unexpected behavior. For now, it might be okay to document this behavior and such plugins would still need to leverage plugins.security.system_indices.indices: setting, wdyt?

[cwperks]

For now, it might be okay to document this behavior and such plugins would still need to leverage plugins.security.system_indices.indices: setting, wdyt?

That's what I was thinking as well. I will update our developer documentation and corresponding pages on the documentation website to accurately reflect what this setting does to provide protection to system indices for plugins in the cluster.

[cwperks]

Is there an efficient way to form a "union" set of plugin's system indices across all nodes?

We could potentially use the cluster state to keep track of the primary list

[shikharj05]

We could potentially use the cluster state to keep track of the primary list

This could potentially explode the cluster state by a lot. For e.g. consider a 100/500 node cluster with 30 plugins running.

[cwperks]

All PRs associated with this issue have now been merged. Closing the issue.

[cwperks]

Removing 2.16 label and adding 2.17.