Refining UX around user privileges

[alisonelizabeth]

Problem

A majority of our apps do not have fine-grained privilege controls. For example, a user might only have a read privilege for an application, but create/update/delete actions would still display in the UI. A user could attempt to perform an action, but ultimately get back a 403 response from Elasticsearch. It is poor UX to present an action to a user that they ultimately do not have permissions for. It also leads to an unnecessary HTTP request; if we know the permissions up front, we can hide any actions that are not permissible and not allow the request to proceed.

On the flip side, sometimes we have defined “required” privileges in an app when in fact not all are required to use parts of the application. For example, Ingest Node Pipelines currently requires manage_ingest_pipelines and cluster:monitor/nodes/info cluster privileges. However, cluster:monitor/nodes/info is only necessary to create or update a pipeline (#63850 (comment)). We should not block a user from viewing the list of pipelines in the UI in this scenario.

More holistically speaking, we have not done a great job at testing our existing privileges support, and some apps are not even accounting for privileges. For example, CCR requires an unnecessary privilege (#76690), while composable (v2) templates does not check for privileges though it requires the manage_index_templates privilege. Some apps are also using a one-off approach and not utilizing the shared authorization library. See more details below.

What we currently support

There is existing support for privileges to an extent:

• The introduction of Hide management sections based on cluster/index privileges #67791 allows management sections to be hidden based on cluster/index privileges
  • The effect of this still needs to be assessed. I think there is potentially duplication of efforts in some of our apps (CCR, Ingest Node Pipelines, License Management, more?)
• We have an authorization library in es_ui_shared that provides a common way to fetch privileges and display a "not authorized" prompt ([ES-UI] Authorization lib to control access to feature & app sections #40150, [ESUI] Move authz lib out of snapshot restore #63947)
  • This approach is currently implemented in Snapshot + Restore, Ingest Node Pipelines, and the Component Templates section of Index Management
• Other apps not using the auth lib have "one-off" approaches:
  • Data streams hides delete action (Added data streams privileges to better control delete actions in UI #83573)
    • As far as I'm aware, this is the only instance where we are hiding an action for a user that does not have sufficient privileges.
  • CCR checks for cluster privileges (related code)
  • Upgrade Assistant checks for 403s (related code)
  • License management checks for cluster privileges (related code)
  • Watcher checks for 403s (related code)

Proposal

Move to a more uniform and granular approach to prevent user actions in the UI when permissions aren't valid. We should not show actions in the UI that a user does not have permission to execute on, and we should not block the entire UI if the user only has read privileges. We should build upon the existing authorization library so apps follow a consistent approach.

As part of this work, we could also consider rendering a callout that indicates certain tasks that are not allowed in the UI due to missing privileges.

Rough example:

** Should consider if this approach is too obtrusive, or, at the least, add the ability to hide or collapse the callout.

As part of this effort, we will first need to do an audit of our existing apps in order to determine the proper privileges, as well as make an assessment whether it's worth the effort to invest in all of our apps, or if some should take precedence over others. Updating the documentation to reflect security restraints should also be included as part of this work.

Related issues

There are a number of related issues open that should be addressed as part of this work.

• CCR requires unnecessary manage privilege #76690
• Read-only mode for Index management #77347
• Refine privilege-checking UX in Index Management #77376
• [Index management] Make UI resilient to failing _cat/aliases call #46126
• [Watcher UI] watcher_admin role unable to create threshold alert #39532

[elasticmachine]

Pinging @elastic/es-ui (Team:Elasticsearch UI)

[elasticmachine]

Pinging @elastic/kibana-management (Team:Kibana Management)

[mattkime]

Related to #195123