[Cases] RFC: RBAC

[cnasikas]

Summary

Cases RBAC mechanism allows Kibana solutions (applications) to use cases scoped to their realm.

Requirments

1. Ensure users can only create, modify and consume Cases 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 a case, but can't change it.
3. Create a Cases feature that will allow administrators to decide which users can create and modify Cases and which users can only read these Cases.

Motivation

Cases would be moved out of security solution for other applications within Kibana to be able to use cases. Users with permissions only to one solution, for example, Observability, should have access to the cases created only by Observability. Similarly, another user with permissions to another solution, for example, Security Solution, should not be able to have access to Observability's cases and vice-versa.

For that reason, similar to the Alerting framework, Cases need their own RBAC. The needs of the Cases RBAC are simpler as there is no notion of the consumer as in alerts.

Detailed design

Saved objects

Cases consist of six saved object types: cases, cases-sub-case, cases-user-actions, cases-comments, cases-connector-mappings, and cases-configure. The first four saved object types are related to cases and the last two are related to the configuration of the Cases solution. A user to view or create a case(s) needs to interact with cases, cases-sub-case, cases-user-actions, and cases-comments. A user to view or change the configuration needs to interact with cases-connector-mappings, and cases-configure. From the RBAC perspective, all saved object types will be treated as one. A user will either have permissions to read or write to all of them or to neither of them. A user cannot have partial access to some of the saved object types. This will make it easier to define the Case's privileged actions.

Each saved object will have an extra attribute called owner that will denote the solution that created this saved object. For example, if a case is created in the Observability plugin we will set the owner field to observability. If a case is created in the Security Solution plugin we will set the owner field to securitySolution. This field will be passed as a parameter to the API that handles creating a case.

Given that at the moment of writing only Security Solution creates cases migration will be easy. All saved objects created so far will be migrated to have owner: 'securitySolution'.

Features

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

When a plugin registers a feature, it can specify which owners of cases 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 owner of cases. For example, in the observability plugin, a new feature privilege will be created called Cases which when granted will give a user access to the observability owner of cases. 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 owner of cases.

A single user can be given access to multiple features and therefore could have access to multiple owners of cases.

Spaces

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

Cases privilege actions

Read
cases:${version}:${owner}/get: A user can get a case, a comment, a user action, or a configuration.
cases:${version}:${owner}/find: A user can get all cases, all comments or all user actions.

Write
cases:${version}:${owner}/create: A user can create a case, a comment, a user action, or a configuration.
cases:${version}:${owner}/update A user can update a case, a comment, a user action, or a configuration.

Case client

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

Example of the Cases Client interface:

export interface CasesClient {
  addComment(args: CasesClientAddComment): Promise<CaseResponse>;
  create(theCase: CasePostRequest): Promise<CaseResponse>;
  get(args: CasesClientGet): Promise<CaseResponse>;
  update(args: CasesPatchRequest): Promise<CasesResponse>;
}

Routes

Some of the routes of the Cases API use the cases 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 casesClient = context.cases.getCasesClient();
const id = request.params.case_id;
const theCase = await casesClient.get({ id });

Authorization class

The Cases 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: (owner: string, operation: string) => void;
}

High-level authorization flow

Drawbacks

• Complexity added by the RBAC.

Alternatives

A saved object type can be created per solution and use the security plugin RBAC. Given that cases needs, at the moment of writing, six saved object types to operate, creating that many saved object types per solution will make it very complex, if not impossible, to support pagination, filtering, and pagination.

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.

[elasticmachine]

Pinging @elastic/security-threat-hunting (Team:Threat Hunting)

[elasticmachine]

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

[zez3]

If a session based token (#94518) is to be securely stored per user then it would make sense to also include this in the future cases RBAC implementation

[cnasikas]

cc @XavierM @jonathan-buttner @mikecote @gmmorris @legrego @kobelb @asnehalb

[legrego]

@cnasikas thank you for taking the time to write down your proposal. This is immensely helpful, and we appreciate the thought that went into this!

I made a google docs version of your proposal, in order to facilitate discussion. In the interest of transparency, this is a public document (view only), but anyone at Elastic is free to edit. Those in the public who wish to comment can do so by replying to this issue instead.

https://docs.google.com/document/d/138QJNOGqRJKeFtV2Ic96fc9DxGyxoeMwheI6RPcMEOY

[cnasikas]

cc @cyrille-leclerc @arisonl

[cnasikas]

If a session based token (#94518) is to be securely stored per user then it would make sense to also include this in the future cases RBAC implementation

@zez3 The cases RBAC has to do with how cases authorize Kibana users when accessing cases saved objects and not with connectors & external services.

[cnasikas]

Implemented in #95058