Security migrations

[legrego]

The set of features that Kibana offers has exploded since Kibana's privilege model was first envisioned in the early days of 6.x. At the time, we made a number of assumptions, some of which are starting to break down.

We need to enhance our privilege model to account for the new types of features that Kibana offers, and come up with a migration plan which removes the limitations outlined below.

Static feature identifiers

Features often evolve over time, and their original names don't always make sense. We don't allow feature ids to change today, as they are used as part of the privilege identifier that we serialize and persist to ES.

Examples:

• SIEM -> Security
• Alerting -> Alerts (https://github.com/elastic/kibana/issues/68994)
• Ingest Manager -> Fleet (https://github.com/elastic/kibana/pull/83200)
• Uptime -> Synthetics

Static privilege identifiers

Each Kibana feature that opts into RBAC gets two "primary" feature privileges: all and read. These privileges are registered with Elasticsearch using their feature id as a prefix:

Example: Feature dashboard has an all and read privilege, which gets us the following ES Application Privileges:

• feature_dashboard.all
• feature_dashboard.read

These are the privileges which are assigned to roles directly. Renaming either the feature id or the privilege id would result in existing roles no longer having access to these features, since they were granted privileges which no longer exist.

Static capability keys

Each feature is given a key within the capabilities object, and this key is the same as its feature id. For example, the dashboard feature has a capabilities section at capabilities.dashboard. Given the static feature identifiers described above, it's not possible to rename these keys.

Examples:

• The dashboards app has a capabilities key of dashboard. Ideally these would be consistent.

Splitting one feature into several smaller features

The Security Solution is a sprawling feature with a lot of functionality. There is a desire to split this out into distinct features that can be individually toggled. While we could solve this with sub-feature privileges, this would be inconsistent with the approach that o11y has taken. Furthermore, using sub-feature privileges in this way prevents us from offering more granularity in the future, if each of these smaller components wanted to offer their own set of sub-feature privileges.

Another example is Fleet. There is an interest in splitting the Integrations and Fleet privileges. This requires more fine-grained permissions for each feature and thus more effort/complexity.

Moving a sub-feature privilege to a top-level feature

Sometimes, a sub-feature privileges gets so large that it deserves to become its own top-level feature. Examples:

• Security Solution -> Cases
• Security Solution -> Management

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[kobelb]

I've also seen situations where we almost needed the ability to split a feature into two separate features, but we were able to catch it in time.

[legrego]

I've also seen situations where we almost needed the ability to split a feature into two separate features, but we were able to catch it in time.

For posterity, this came up again today with the Security Solution. I updated the issue description to reflect this need.

[legrego]

I've also seen situations where we almost needed the ability to split a feature into two separate features, but we were able to catch it in time.

For posterity, this came up again today with the Security Solution. I updated the issue description to reflect this need.

Updated the description again to add Fleet/Integrations as another feature that wants to be split out