Kibana alerting v2 privileges
Kibana alerting v2 uses Elasticsearch index-level security to control access to alert data, combined with Kibana feature privileges for rule and policy management.
To create, edit, and manage Kibana alerting v2 rules, you need:
- Kibana feature privilege:
Rules V2with the appropriate access level (read, create, edit, or all). - Elasticsearch index privileges: Read access to the source indices your rules query (for example,
logs-*,metrics-*).
Rule execution uses the API key of the user who created or last updated the rule. This means the rule runs with the privileges of that user. If the user's privileges change, rule execution reflects those changes.
To create and manage notification policies, you need:
- Kibana feature privilege:
Rules V2with create or edit access. - Workflow permissions: To add a workflow as a destination on a policy, you need permissions for that workflow. This prevents privilege escalation through policy configuration.
To view and take actions on alerts (acknowledge, snooze, tag, assign), you need:
- Kibana feature privilege:
Rules V2with at least read access. - Elasticsearch index privileges: Read access to
.alerts-events-*for viewing alerts. Write access to.alerts-actionsfor taking alert actions.
Because Kibana alerting v2 alert events are stored in standard Elasticsearch indices, any user with read access to .alerts-events-* can query them in Discover and use them in dashboards. No additional Kibana privileges are required beyond the standard Discover feature access.
Rule and notification policy management respects Kibana space boundaries. Rules created in one space are not visible in another. Alert events are indexed globally, but UI access is filtered by space.
Rules and notification policies use API keys for execution:
- An API key is created when a rule or policy is saved.
- The API key inherits the privileges of the user who created it.
- You can update the API key from the rule or policy management page if the original user's privileges change.