Warn if role grants access to Kibana index

[legrego]

Summary

We should surface a warning on the Role Management UI when users specify an index privilege that grants access to the Kibana index (.kibana by default).

Motivation

Granting direct access to this index is something we have required for Kibana users up until version 6.4, but is no longer necessary or recommended. The introduction of Kibana Application Privileges removes this requirement, and is deprecated when used to grant access to Kibana itself.

Granting direct index access bypasses the security controls put in place for Spaces and Feature Controls, so it is important that we educate users when they grant direct index access.

Challenges

Most users specify the index privileges using either a specific index name (e.g. .kibana) or a rudimentary wildcard (e.g. .kibana*). These two scenarios are easy enough for us to work with, and aren't problematic.

This gets non-trivial though for any other pattern. Elasticsearch allows index privilege names to use the Lucene Regex syntax, which is something we can't replicate in a browser/Node environment.

Possible solutions

1) Ignore complex patterns

We can easily determine if a pattern like .kibana* matches, and warn appropriately. The problem is that more complex patterns would be ignored, so we would have a whole class of false negatives where we would not warn when we should be. This could give users a false sense of security.

Pros

1. Easy to implement
2. Low overhead

Cons

1. Produces false negatives

2) Query a placeholder document

We could leverage the Regexp query to make this determination. Kibana could create a document within the .kibana index which contains the name of the kibana index. We could then test to see if any of the patterns match the kibana index by issuing regex queries against that document, to see if it is returned.

Pros

1. No changes to Elasticsearch
2. No false negatives/positives. This should produce an exact answer every time.

Cons

1. Slightly more overhead, although likely not a problem.
2. Introduces a pointless document into the Kibana index for the sole purpose of this check.

3) Allow a dry run of _has_privileges from Elasticsearch

Elasticsearch exposes a _has_privileges API today which can answer this question. The problem is that it is meant to run in the context of a user, so it answers the question for a user, rather than for a particular role (or a role definition that hasn't even been created yet).

Pros

1. No false negatives/positives. This should produce an exact answer every time.

Cons

1. Introduces a completely new API for the sole purpose of this UI check.

4) Expose lucene regex tester from Elasticsearch

Elasticsearch could expose a regex tester which wraps the Lucene Regex syntax. Kibana could then use this to make a determination.

Pros

1. No false negatives/positives. This should produce an exact answer every time.

Cons

1. Introduces a completely new API for the sole purpose of this UI check.

[elasticmachine]

Pinging @elastic/kibana-security

[legrego]

Closing as obsolete:
Starting in 8.0. access to system indices will not be granted by default. Access will require an explicit action by the administrator when configuring the role.