Allowing the kibana system role to get/put privileges

[kobelb]

For Kibana to take advantage of the application privileges, the Kibana server will need to update it's privileges when they don't exist or are different than expected. Also on start-up the Kibana server will create the equivalent of the "kibana_user" and "kibana_dashboard_only_user" roles with the appropriate "resource" when they don't exist as "non reserved roles" so that users are able to modify the privileges associated with these roles.

[joshbressers]

This is potentially dangerous if Kibana can update privileges at will. How often do we envision this having to happen?

[kobelb]

A discussion happened with regard to this PR in the #kibana-security Slack channel, and I've attempted to summarize and expound upon it here.

The ability to PUT privileges on start-up isn't our main concern at this point, as these are only used by the Kibana application for asserting it's own access-control.

The primary concern at this point is the ability for the Kibana system role to update arbitrary roles.

Kibana is currently creating roles on start-up for the equivalent of the "kibana_user" and "kibana_dashboard_only_user" when the xpack.security.rbac.enabled: true setting is set in the kibana.yml and the roles don't exist in Elasticsearch already. We are currently doing so for a few reasons:

1. We only need these roles when xpack.security.rbac.enabled: true in the kibana.yml and we didn't want to be using reserved roles for these as this could potentially clutter up the list of roles when they weren't being utilized.
2. When we do use a reserved role for the "kibana_user" this can't be modified, so the user isn't able to modify anything on the role, including the Kibana privileges which will commonly be modified as soon as Spaces is a reality
3. We've historically only created "kibana_user" and "kibana_dashboard_only_user" roles for the default Kibana "tenant" and made the user manually create these roles for the other "tenant", creating these automatically on startup was supposed to ease this process. This one I'm less concerned with, as hopefully multi-tenant deployments just stop happening as soon as Spaces is released.

These are the existing solutions that I've thought of, or @joshbressers proposed in the #kibana-security Slack channel.

1. Require a user with the manage_security cluster privilege login to Kibana first to create the roles.
2. Utilize a reserved role for the new "kibana_user" and "kibana_dashboard_only_user" roles
3. Allow the Kibana server to only create new roles, not update existing roles

[elasticmachine]

Pinging @elastic/es-security

[kobelb]

After some discussion, we've removed the need for the Kibana system role needing to GET/PUT roles, so this only adds the ability to for the Kibana system role to GET/PUT privileges.

[jaymode]

This is fine with me for the branch right now. As long as @tvernum concurs, then lets merge this as is until we figure out how we're going to limit the scope of modifying privileges.

[tvernum]

Per @jaymode's comments, this is good for the branch but we'll need to work out the longer term plan.