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.
If you use the security plugin alongside alerting, you might want to limit certain users to certain actions. For example, you might want some users to only be able to view and acknowledge alerts, while others can modify monitors and destinations.
The security plugin has three built-in roles that cover most alerting use cases:
alerting_full_access. For descriptions of each, see Predefined roles.
If these roles don’t meet your needs, mix and match individual alerting permissions to suit your use case. Each action corresponds to an operation in the REST API. For example, the
cluster:admin/opensearch/alerting/destination/delete permission lets you delete destinations.
How monitors access data
Monitors run with the permissions of the user who created or last modified them. For example, consider the user
jdoe, who works at a chain of retail stores.
jdoe has two roles. Together, these two roles allow read access to three indices:
jdoe creates a monitor that sends an email to management whenever the number of returns across all three indices exceeds 40 per hour.
Later, the user
psantos wants to edit the monitor to run every two hours, but
psantos only has access to
store1-returns. To make the change,
psantos has two options:
- Update the monitor so that it only checks
- Ask an administrator for read access to the other two indices.
After making the change, the monitor now runs with the same permissions as
psantos, including any document-level security queries, excluded fields, and masked fields. If you use an extraction query to define your monitor, use the Run button to ensure that the response includes the fields you need.
(Advanced) Limit access by backend role
Out of the box, the alerting plugin has no concept of ownership. For example, if you have the
cluster:admin/opensearch/alerting/monitor/write permission, you can edit all monitors, regardless of whether you created them. If a small number of trusted users manage your monitors and destinations, this lack of ownership generally isn’t a problem. A larger organization might need to segment access by backend role.
First, make sure that 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.
Next, enable the following setting:
Now when users view alerting resources in OpenSearch Dashboards (or make REST API calls), they only see monitors and destinations that are created by users who share at least one backend role. For example, consider three users who all have full access to alerting:
jroe are on the same team at work and both have the
analyst backend role.
psantos has the
human-resources backend role.
jdoe creates a monitor,
jroe can see and modify it, but
psantos can’t. If that monitor generates an alert, the situation is the same:
jroe can see and acknowledge it, but
psantos can’t. If
psantos creates a destination,
jroe can’t see or modify it.