Configurable base privileges

[kobelb]

This is an alternative solution to what is described in #38571

Problem

Currently, all feature privileges are automatically granted when a user assigns the base privilege of all or read. This is beneficial when new features are added to Kibana, the user automatically gets access to them if they have all or read base privileges. This mirrors the way that the Elasticsearch index and cluster all privileges work.

This becomes a hurdle when it comes to converting applications like Machine Learning or Reporting which currently rely on their own reserved roles to grant access to be first-class Kibana Privilege features. If we were to add a new Machine Learning feature, and use the Kibana Privileges to authorize the user, now any user that has the Kibana all base privilege now gets access to Machine Learning, when it used to require that the user was assigned the machine_learning_admin or machine_learning_user roles.

This behavior also potentially create a lot of manual work for administrators as we add new features to Kibana. If we were to add a feature to Kibana which an administrator doesn't want everyone to have access to, at this point they'd have to go through and modify all custom roles to no longer use the all or read base privileges, but instead use feature level privileges. This is even more work if the administrator is using the kibana_user reserved role to grant access to Kibana. Reserved roles can't be modified, so the administrator would have to create a new custom role and then update all users and role-mappings to use the new custom role.

Solution

To solve both of these problems, we could allow the features which are part of the base all and read privileges to be configurable. This would allow us to add features in a minor that aren't automatically part of all or read until an administrator opts-in to this behavior. This would also allow the user to change the privileges which are granted with the existing roles, without requiring the administrator to mass update roles, or users/role-mappings. The ability to do so would only granted to users with the manage_security cluster privilege.

Outstanding Questions

• Where do we store the list of features which are considered part of the all and read base privileges? Are we comfortable storing these in the .kibana* index? Starting in 7.0, end-users no longer have direct index access, so this is theoretically possible.

• Assuming there is a way to detect whether there's a new installation of Kibana, as opposed to an upgrade from a previous version, should we consider having new installations have all features part of "all" and "read" during a minor version? This would potentially allow new installations to automatically have applications like Machine Learning and Reporting part of the all and read base privileges, while maintaining the behavior of existing installations?

Tasks

the following is a very rough list of tasks, it's likely incomplete

• UI for managing features which are part of the base privileges
• API Endpoints
  • PUT base privilege definition - we'll create the saved object itself and then synchronize the privilege definition to Elasticsearch
  • GET base privilege definition - we should additionally warn the user if the saved object definition is out of sync with the actual privilege definitions
  • Add the ability to secure API routes based off of cluster privileges, and use this for the PUT endpoint
• On start-up augment the ES privileges sync to be based on the base privilege saved object if it exists
• Modify downstream consumers of the privilege definition to adapt to the privilege definition being asynchonously built, and potentially null at the time of consumption
• Add API integration tests to ensure the PUT base privilege definition has the intended affect on the _has_privileges call to Elasticsearch
• Add functional UI smoke-tests

[elasticmachine]

Pinging @elastic/kibana-security

[kobelb]

Closing this out in favor of #38571