[RAC] [Alerts] [RBAC]

[dhurley14]

Summary

Alerts as data RBAC will allow Kibana solutions (applications) to use alerts as data scoped to their realm (naming TBD).

Requirements

1. Ensure users can only create, modify and consume Alerts that are owned by solutions that they have access to (for example, only a user with Observability access should be able to create an Observability case).
2. Ensure Read and All privileges are respected, so users who are, for example, read-only users can only read an Alert, but can't change it.
3. Create an Alerts feature that will allow administrators to decide which users can create and modify Alerts and which users can only read Alerts.

Motivation

Alerts as data is part of the broader initiative for a unified alerting experience. Currently only the security solution provides an interface to alerts as data through the .siem-signals-<space> index but the hope is to provide this across solutions and for the stack.

Considering this, we would like to provide way to prevent users from accessing alerts they are not privileged to access. If a user only has permission to read alerts from Observability, we do not want to display security solution alerts alongside those Observability alerts (or vice-versa).

For that reason, similar to the Alerting framework, Alerts needs its own RBAC system. The needs of the Alerts RBAC are simpler as there is no notion of the producer as in the alerting framework.

Detailed design

Alerts data index

Each solution has the ability to create rules that will generate alerts and notifications (actions). Because we are not using saved objects the RBAC implementation will differ from other teams (e.g. kibana alerting framework, cases etc.) Although Observability has sub-features like APM and Logs, this feature is intended to tackle larger-scoped application-level authorization. In the future we can see possibly adding sub-feature level RBAC support. The plan is to append a consumer / scope / class / client_scope field to each alert to determine which users have CRUD access to what alerts.

Migrating the current alerts from .siem-signals index into this unified index will be straightforward just adding a consumer for 'securitySolution'. Observability alerts will be a little more difficult to migrate into this unified index but this migration process will be defined a bit later.

Features

An Alerts feature will be created for Observability and an Alerts sub-feature for Security Solution. Administrators can specify if the access to the Alerts feature will be all, read. or none.

When a plugin registers a feature, it can specify which consumers of alerts a user could be given access to when granted that specific feature privilege. For now, we can assume that a single feature will only register a single consumer of alerts. For example, in the observability plugin, a new feature privilege will be created called Alerts which when granted will give a user access to the observability alerts consumer. This will be very similar to the Security Solution plugin. When a user is granted access to the Security feature within the Security Solution plugin they will be granted access to the securitySolution alerts consumer.

A single user can be given access to multiple features and therefore could have access to multiple alerts consumers.

Spaces

The RBAC will be spaces oriented meaning that space user's permission will be checked before an action.

Alerts privilege actions

[NOTE]: think through actions of t1_analyst vs hunter etc...

i.e. t1_analyst would have "Read" for security solution but "All" for Alerts sub-feature within the security solution to allow them the ability to update alert statuses but not modify rules or anything in the security solution, nor view Observability alerts.

Read
// search strategy through the timeline
rac:${spaceid}:${version}:${consumer}/get: A user can get an alert.
rac:${spaceid}:${version}:${consumer}/find: A user can query all alerts.

Write
rac:${spaceid}:${version}:${consumer}/update: A user can update a status to be open, closed, and in-progress.

Alerts client (RAC)

The alerts client exports a set of functions to facilitate alerts operations. The alerts client is exported for other plugins to be able to create, view or update alerts. The alerts client can be accessed either from the route context or within the plugin's lifecycles.

Example of the RAC Client interface:

export interface RacClient {
  get(args: RacClientGet): Promise<AlertsResponse>;
  // search(args: RacClientQuery): Promise<AlertsResponse>;
  
  // currently, security solution uses POST over PATCH but open to suggestions
  update(args: RacPostRequest): Promise<AlertsResponse>;
}

Routes

Some of the routes of the Alerts API use the Alerts client to serve the request. Most of them do not. We are in the process of moving route logic to a dedicated function for each route inside the case client.

Example:

const racClient = context.alerts.getRacClient();
const id = request.params.alert_id;
const theAlert = await racClient.get({ id });

Authorization class

The Alerts RBAC implementation will follow the alerting team's implementation by creating an Authorization class that each CRUD code path will call to determine if the requesting user is authenticated for that specific operation.

An audit log mechanism will be implemented to log every success or failure of the authorization class.

interface Authorization {
  // Asserts that the user is authorized to operate.
   ensureAuthorization: (className: string, operation: string) => void;
}

High-level authorization flow

Future

The need of other Kibana plugins to use the same RBAC may arise. We need to think about how we can generalize the RBAC to support other Kibana plugins.

---

Tasks:

• Authorization class (PR)
• Write an "update" handler with RBAC (PR)
• Write a "read / find / get" handler with RBAC (PR)
• UI changes:
  • update UI settings in the solutions section of stack management page / privileges [RAC] - RBAC UI advanced settings updates #95823 (PR for Security)
  • Update the client to reference the correct identifier (temp name: client_scope) [RAC] RBAC UI Changes #95821 (PR)
  • UI failure message design [RAC] - RBAC UI changes notify user of auth #95827 (PR)
• RBAC integration with Security Solution search strategy @yctercero (PR)
• Update alert status API to use Alert RBAC (PR)
• RBAC bulk update API for alerts @dhurley14 (PR)
• Update Alerts page histogram to use new RBAC find @dhurley14 (PR)
• Integrating RBAC with rules that query alerts indices (alerts on alerts) @marshallmain [RAC] - Integrating RBAC with rules that query alerts indices #102951 (PR)
• Addition of space ids to alert documents and updating authorization class to check this @dhurley14 (PR)

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[kobelb]

/cc @elastic/kibana-security just a heads up that we're going to have another client implementing their own RBAC that will likely need a review from you all.

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)