AWS opensearch-service: Document Dashboards breakage when allow_explicit_index is false
Summary
Expanded guidance on setting rest.action.multi.allow_explicit_index to false, explaining that it breaks OpenSearch Dashboards (saved objects, startup migration, engine upgrades) and that the two features are mutually exclusive, with a partial-remediation alternative.
Security assessment
The setting rest.action.multi.allow_explicit_index is a security-relevant control that restricts access to subresources via bulk/mget/msearch; this change documents its operational consequences and a partial-remediation approach (deny specific users access to those APIs), which is security-adjacent hardening guidance rather than a fix for a specific vulnerability.
Evidence
Dashboards isn't supported on domains where this option is set to `false`. The two features are mutually exclusive, and setting the option back to `true` is the only way to restore Dashboards.
Diff
diff --git a/opensearch-service/latest/developerguide/ac.md b/opensearch-service/latest/developerguide/ac.md index e0805c1ca..cdbb06795 100644 --- a//opensearch-service/latest/developerguide/ac.md +++ b//opensearch-service/latest/developerguide/ac.md @@ -567 +567,12 @@ In this situation, the access policy fails to fulfill its intent. To prevent use -[OpenSearch Dashboards](./dashboards.html) relies heavily on mget and msearch, so it is unlikely to work properly after this change. For partial remediation, you can leave `rest.action.multi.allow_explicit_index` as true and deny certain users access to one or more of these APIs. +[OpenSearch Dashboards](./dashboards.html) relies heavily on the bulk, mget, and msearch APIs, so setting this option to `false` breaks it. Expect the following: + + * Dashboards can't read its own saved objects, because it retrieves them with mget and msearch. Index patterns, saved searches, visualizations, and dashboards all appear empty or fail to load, even when Dashboards itself reports that it is healthy. + + * Dashboards might not start at all. Dashboards stores its own state (index patterns, visualizations, and dashboards) in the OpenSearch Dashboards index. Whenever the saved-object format changes (for example, after an engine version upgrade), Dashboards migrates that state into a new index on startup. The migration writes documents with the bulk API and names the index in the request body, so it fails while this option is `false`. Dashboards doesn't recover from this on its own, and it reports `OpenSearch Dashboards server is not ready yet` rather than a message that names this option. For more information, see [Dashboards is stuck at "server is not ready yet" (HTTP 503 not ready error)](./dashboards-troubleshooting.html#dashboards-troubleshooting-not-ready). + + * An engine version upgrade might not finish. Every upgrade verifies that Dashboards is healthy before it completes, and a Dashboards that can't start blocks that check. You also can't change advanced options while an upgrade is in progress, so if you intend to set this option back to `true`, do it **before** you start an upgrade. If an upgrade has already stalled, contact [AWS Support](https://aws.amazon.com/premiumsupport/). + + + + +Dashboards isn't supported on domains where this option is set to `false`. The two features are mutually exclusive, and setting the option back to `true` is the only way to restore Dashboards. If you need to restrict subresource access this way, plan on not using Dashboards on that domain. For partial remediation that keeps Dashboards working, you can instead leave `rest.action.multi.allow_explicit_index` as true and deny certain users access to one or more of these APIs.