This version of the OpenSearch documentation is no longer maintained. For the latest version, see the current documentation. For information about OpenSearch version maintenance, see Release Schedule and Maintenance Policy.
Index management security
Using the Security plugin with index management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies.
All index management data are protected as system indexes, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indexes. For more information, see System indexes.
The Security plugin comes with one role that offers full access to index management:
index_management_full_access. For a description of the role’s permissions, see Predefined roles.
With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indexes. For example, if a user wants to use the REST API to attach a policy that executes a rollup job to an index named
system-logs, they would need the permissions to attach a policy and execute a rollup job, as well as access to
Finally, with the exceptions of Create Policy, Get Policy, and Delete Policy, users also need the
indices:admin/opensearch/ism/managedindex permission to execute ISM APIs.
(Advanced) Limit access by backend role
You can use backend roles to configure fine-grained access to index management policies and actions. For example, users of different departments in an organization might view different policies depending on what roles and permissions they are assigned.
First, ensure your users have the appropriate backend roles. Backend roles usually come from an LDAP server or SAML provider. However, if you use the internal user database, you can use the REST API to add them manually.
Use the REST API to enable the following setting:
With security enabled, only users who share at least one backend role can see and execute the policies and actions relevant to their roles.
For example, consider a scenario with three users:
Jill, who have the backend role
Jane, who has the backend role
John wants to create a policy that performs a rollup job on an index named
John would need a backend role that has permissions to access that index, create relevant policies, and execute relevant actions, and
Jill would be able to access the same index, policy, and job. However,
Jane cannot access or edit those resources or actions.