Kibana-wide HTTP route authorization

[jportner]

Currently, consumers do not have to specify any authorization controls when registering HTTP routes.

They can optionally use API access tags (access:<tag>). Otherwise, the route will rely on the authorization checks that are automatically applied for any saved object CRUD operations or other Elasticsearch API calls with the user's credentials.

This has been a large blind spot for us, and we are seeing more consumers register routes that rely on the Kibana system user's privileges (for example, to create a data view when an app is first accessed, since the end user might not have privileges to create a data view).

We could take the following steps:

1. Conduct an audit to determine how many routes do not have any access tags applied
2. Require all consumers to either register at least one access tag, or explicitly opt out of using authorization

It might also be useful to provide some new mechanism to allow consumers to specify that authorization checks should be applied based on a given feature privilege, as an alternative to access tags.

Note: there are performance considerations here, any authorization check currently will rely on an extra round-trip to Elasticsearch (we don't have a way to do an authN+authZ check in a single API call)

[elasticmachine]

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