Each permission in the Security plugin controls access to some action that the OpenSearch cluster can perform, such as indexing a document or checking cluster health.
Most permissions are self-describing. For example, `cluster:admin/ingest/pipeline/get` lets you retrieve information about ingest pipelines. _In many cases_, a permission correlates to a specific REST API operation, such as `GET _ingest/pipeline`.
Despite this correlation, permissions do **not** directly map to REST API operations. Operations such as `POST _bulk` and `GET _msearch` can access many indexes and perform many actions in a single request. Even a simple request, such as `GET _cat/nodes`, performs several actions in order to generate its response.
For this request to succeed, you must have the following permissions for `test-index`:
- indices:data/write/bulk*
- indices:data/write/delete
- indices:data/write/index
- indices:data/write/update
These permissions also allow you add, update, or delete documents (e.g. `PUT test-index/_doc/tt0816711`), because they govern the underlying OpenSearch actions of indexing and deleting documents rather than a specific API path and HTTP method.
If you want a user to have the absolute minimum set of permissions necessary to perform some function—the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege)—the best way is to send representative requests to your cluster as a new test user. In the case of a permissions error, the Security plugin is very explicit about which permissions are missing. Consider this request and response:
[Create a user and a role]({{site.url}}{{site.baseurl}}/security/access-control/users-roles/), map the role to the user, and start sending signed requests using curl, Postman, or any other client. Then gradually add permissions to the role as you encounter errors. Even after you resolve one permissions error, the same request might generate new errors; the plugin only returns the first error it encounters, so keep trying until the request succeeds.
Rather than individual permissions, you can often achieve your desired security posture using a combination of the default action groups. See [Default action groups]({{site.url}}{{site.baseurl}}/security/access-control/default-action-groups/) for descriptions of the permissions that each group grants.
These permissions are for the cluster and can't be applied granularly. For example, you either have permissions to take snapshots (`cluster:admin/snapshot/create`) or you don't. The cluster permission, therefore, cannot grant a user privileges to take snapshots of a select set of indexes while preventing the user from taking snapshots of others.
Cross-references to API documentation in the permissions that follow are only intended to provide an understanding of the permissions. As stated at the beginning of this section, permissions often correlate to APIs but do not map directly to them.
{: .note }
### Ingest API permissions
See [Ingest APIs]({{site.url}}{{site.baseurl}}/api-reference/ingest-apis/index/).
See [API tools]({{site.url}}{{site.baseurl}}/security-analytics/api-tools/index/).
| **Permission** | **Description** |
| :--- | :--- |
| cluster:admin/opensearch/securityanalytics/alerts/get | Permission to get alerts |
| cluster:admin/opensearch/securityanalytics/alerts/ack | Permission to acknowledge alerts |
| cluster:admin/opensearch/securityanalytics/detector/get | Permission to get detectors |
| cluster:admin/opensearch/securityanalytics/detector/search | Permission to search detectors |
| cluster:admin/opensearch/securityanalytics/detector/write | Permission to create and update detectors |
| cluster:admin/opensearch/securityanalytics/detector/delete | Permission to delete detectors |
| cluster:admin/opensearch/securityanalytics/findings/get | Permission to get findings |
| cluster:admin/opensearch/securityanalytics/mapping/get | Permission to get field mappings by index |
| cluster:admin/opensearch/securityanalytics/mapping/view/get | Permission to get field mappings by index and view mapped and unmapped fields |
| cluster:admin/opensearch/securityanalytics/mapping/create | Permission to create field mappings |
| cluster:admin/opensearch/securityanalytics/mapping/update | Permission to update field mappings |
| cluster:admin/opensearch/securityanalytics/rules/categories | Permission to get all rule categories |
| cluster:admin/opensearch/securityanalytics/rule/write | Permission to create and update rules |
| cluster:admin/opensearch/securityanalytics/rule/search | Permission to search for rules |
| cluster:admin/opensearch/securityanalytics/rules/validate | Permission to validate rules |
| cluster:admin/opensearch/securityanalytics/rule/delete | Permission to delete rules |
### Monitoring permissions
Cluster permissions for monitoring the cluster apply to read-only operations, such as checking cluster health and getting information about usage on nodes or tasks running in the cluster.
See [REST API reference]({{site.url}}{{site.baseurl}}/api-reference/index/).
These permissions apply to an index or index pattern. You might want a user to have read access to all indexes (that is, `*`), but write access to only a few (for example, `web-logs` and `product-catalog`).
These permissions apply to REST APIs to control access to the endpoints. Granting access to any of these will allow a user the permission to change fundamental operational components of the Security plugin.
Allowing access to these endpoints has the potential to trigger operational changes in the cluster. Proceed with caution.
