Snapshot restore fails with security_exception "no permissions for []" on non-system index (4.14.7 / OpenSearch 2.19.5)
Harishwar Boya
After upgrading from Wazuh 4.14.3 to 4.14.7 (reinstalled the GCS repository plugin on the indexer, reconnected the same bucket), snapshot restores now fail via the dashboard and via the REST API when authenticating as a normal admin-mapped user.
Environment:
- Wazuh 4.14.7 (indexer, dashboard, manager)
- OpenSearch 2.19.5
- 2-node indexer cluster
- GCS snapshot repository
Error (identical via dashboard and curl):
{"error":{"root_cause":[{"type":"security_exception","reason":"no permissions for [] and User [name=Sanstark_internal@011, backend_roles=[admin], requestedTenant=null]"}],"type":"security_exception","reason":"no permissions for [] and User [name=Sanstark_internal@011, backend_roles=[admin], requestedTenant=null]"},"status":403}
What I've confirmed:
- The target index is a normal data index (wazuh-alerts-4.x-YYYY.MM.DD), not a system/security index like .opendistro_security or .kibana*
- User resolves to roles: [own_index, custom_snapshot_management, all_access] via GET _plugins/_security/api/account
- backend_roles: [admin] correctly maps to all_access per GET _plugins/_security/api/rolesmapping/all_access
- plugins.security.enable_snapshot_restore_privilege: true and plugins.security.check_snapshot_restore_write_privileges are both set correctly on both indexer nodes (tried both true and false), confirmed via config file and confirmed the service was restarted with the new config after each change
- No dynamic cluster setting is overriding these (GET _cluster/settings shows nothing relevant under persistent/transient)
- No audit logging is enabled, so I couldn't get more detail from the indexer logs at the moment of failure
Workaround that succeeded:
Authenticating with the admin certificate (admin.pem/admin-key.pem, matching plugins.security.authcz.admin_dn) instead of the normal admin-mapped user bypasses the issue entirely and the restore completes successfully (after handling a separate, expected "index already exists" error with a rename_pattern).
Question:
Is this expected behavior for an all_access user restoring a non-system index, or a gap in the security plugin's privilege evaluation for snapshot restore? I found a similar report in an older mailing list thread (Pradeep, Jan 2023, "Unable to restore the index from s3") with the same exact error, but no root cause was confirmed there either. Happy to provide indexer logs, opensearch.yml, or roles/rolesmapping config if useful.
Md. Nazmur Sakib
Hi Harishwar,
I believe this is not a Wazuh 4.14.7 bug. The empty [] in the error means the plugin blocked the restore before it ever looked at your roles, so all_access doesn't help here. The admin certificate skips the permission check completely, which is why it works.
We see this error when the request resolves to _all (omitted indices, "*", or exclusion-only lists like -.opendistro_security), when include_global_state: true, or when the security index lands in the resolved/renamed list. Dashboards' "restore all indices" sends "*", so it hits this by default.
Try restoring with explicit index names, no wildcards or exclusions, include_global_state: false.
Check this document to learn more: Snapshot Restore.
Similar discussions:
https://github.com/opensearch-project/security/issues/1652
Identical error, backend_roles=[admin] = all_access;
https://github.com/opensearch-project/OpenSearch/issues/2022
Contains the cluster:admin/snapshot/restore for '_all' indices is not allowed for a regular user
https://forum.opensearch.org/t/unable-to-restore-snapshot-with-cluster-state-included/14286
Same error caused by include_global_state
Let me know if you need any further information on this.