Hide management sections based on cluster/index privileges

[legrego]

Summary

Updates the Stack Management application to respond to the user's cluster and index privileges.

Previously, a vast majority of the Stack Management features were visible to all end-users, even if they weren't authorized to take advantage of these features. We were able to hide features within the Kibana section, as they were designed to respond to Kibana's privilege model (aka "feature controls"), but we were not able to hide anything else, as the rest of the stack management features relied on cluster and index privileges which were not under Kibana's control.

This PR allows Kibana to respond to the user's cluster and index privileges in order to toggle visibility for what I'm calling "Elasticsearch Features". As of now, this is limited to the functionality within the Stack Management application.

This does not add any additional security controls. It merely allows Kibana to know when it's safe to show or hide these features in the UI. The responsibility for authorizing access is still governed by Elasticsearch.

Motivation

The primary motivation is to reach feature-parity with the deprecated (and soon to be removed) "Dashboard-only mode". Dashboard-only mode allowed administrators to configure users who could only access the Dashboard application, and nothing else. Feature controls in its current form gets us very close to this behavior, but Stack Management has been a holdout due to its diverging privilege model.

This PR will allow the Stack Management application to be completely hidden if the end-user is not authorized to access any of the underlying features. Additionally, users will only see the management features that they're authorized to use.

Notable changes

Introduces "Elasticsearch Features"

This PR introduces the concept of an "Elasticsearch Feature", which is maintained by the existing features plugin. Elasticsearch features are siblings to the existing Kibana features. A key distinction is that Elasticsearch features are not visible within the Spaces or Role management screens. At this point, they are considered an implementation detail in order for Kibana to respond to the current user's privileges.

We may decide to surface this in the UI at some point in the future.

Renames Feature to KibanaFeature

Now that there are two types of features, we had to rename the existing Feature and FeatureConfig to KibanaFeature and KibanaFeatureConfig in order to distinguish this from ElasticsearchFeature and ElasticsearchFeatureConfig.

Updates authorization checks

Now that Kibana needs to respond to more than Kibana's own privileges, we've had to expand the security plugin's authorization checks to also account for cluster and index privileges. The checkPrivileges* suite of authorization functions have been updated to accept an object of the format:

// Old format
checkPrivileges(['array', 'of', 'kibana', 'privileges']);

// New format
checkPrivileges({
  kibana: ['array', 'of', 'kibana', 'privileges'],
  elasticsearch: {
    cluster: ['array', 'of', 'cluster', 'privileges'],
    index: {
       [indexName: string]: ['array', 'of', 'index', 'privileges']
    }
  }
});

👋 Attention code owners!

Please pay close attention to your review of this PR. This is one of those PRs where the review is as important as the implementation.
If I added a call to registerElasticsearchFeature within your code, then I humbly ask for the following as part of your review:

1. Make sure your management feature still works
2. Pay extra-special attention to any requiredClusterPrivileges, requiredIndexPrivileges, and requiredRoles that I defined as part of the call to registerElasticsearchFeature. I TOOK A GUESS when defining these privileges, as the documentation is sparse (or I can't search very well). If your application requires a different set of privileges to run, then please let me know as part of your review! For this PR, I'm only interested in defining the minimal set of privileges to make your feature function without authorization errors.
3. Create a user with the privileges defined in step 2, and make sure your management feature works as expected. I did this as part of my work on this PR, but this is an invasive change that would benefit from your expertise.
4. I'm being a pain. Please leave a comment in your PR review that indicates that you followed these instructions.

I'm aware that some features offer read-only and read-write access. You are welcome to enhance your feature in a followup PR (and I'm more than happy to help!). My goal for this PR is to know when it's safe to hide or show your feature. Nothing more, nothing less.

Preview of doc changes: https://kibana_67791.docs-preview.app.elstc.co/diff

Resolves #35040
Resolves #35965

[elasticmachine]

Pinging @elastic/ingest-management (Team:Ingest Management)

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[elasticmachine]

Pinging @elastic/uptime (Team:uptime)

[legrego]

bad bot. You all will want to unsubscribe, this will be noisy for quite some time.

[ph]

@jen-huang Can you keep on eye on this issue?

[legrego]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 1246bd1

Build metrics

@kbn/optimizer bundle module count

id	value	diff	baseline
features	11	+2	9

async chunks size

id	value	diff	baseline
management	176.8KB	+2.0B	176.8KB
security	1.0MB	+18.0B	1.0MB
total		+20.0B

page load bundle size

id	value	diff	baseline
features	15.8KB	+2.9KB	12.9KB
management	30.1KB	+573.0B	29.5KB
ml	845.5KB	+686.0B	844.8KB
security	305.7KB	+225.0B	305.4KB
total		+4.3KB

distributable file count

id	value	diff	baseline
default	45522	+4	45518

History

• 💚 Build #73852 succeeded b28a951
• 💚 Build #73768 succeeded fac5cfe
• 💚 Build #73500 succeeded d28ecd6
• 💔 Build #73168 failed fc5eb68
• 💚 Build #72403 succeeded 987c6f4

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream