Support for (builtin) templated roles

[tvernum]

For a number of stack applications securiy administrators need to setup roles with a standard set of privileges over a customisable index pattern:

For example: https://www.elastic.co/guide/en/beats/heartbeat/6.6/beats-basic-auth.html

Create a writer role that has the following privileges:

• Cluster: manage_index_templates and monitor
• Index: write and create_index on the Heartbeat indices

Ideally we would ship that as a reserved role, but because the index pattern is not fixed (our ingest tools have customisible output indices) we can't do that. It would be helpful to be able to ship some sort of builtin template that could be used to create a concrete role over the required indices.

[elasticmachine]

Pinging @elastic/es-security

[tvernum]

As I was writing this up, it occurred to me that an alternative would be for this to be a UI convenience only, which would live in Kibana. That is the "create new role" page in Kibana security management could have a way to prepopulate all the fields except for the index pattern.

That would mean we wouldn't offer a solution that's available through the ES API, but that might be OK.

[legrego]

APM could benefit from this too, as they are in a similar position: We are providing an APM reserved role with privileges against the apm-* index pattern, but end-users are allowed to change the index pattern used to store their data.

[urso]

We will also need manage_ilm.

[andrewvc]

This is really great because this info currently lives in docs, where updating / testing these roles isn't ideal.

If we do add these roles it will be great if we can have QA tests that can validate that they actually work for a given product. Adding ILM, for instance, made the docs for beat responsibilities go out of date.

CC @LeeDr

[LeeDr]

@andrewvc Yes, very important. I reported the ILM issue back on Dec 10th in Beats channel.

But this templated roles is a new concept that certainly has some merit. Maybe the issue is that we don't let users modify the built-in roles. Maybe if they could make a copy of a role and modify it. That way we know they always have the built-in one with a fixed set of privs.

[andrewvc]

@LeeDr ++ to any built-in roles being immutable and parameterize-able somehow.

[albertzaharovits]

Suppose we have integration tests for a built-in role, using some default index pattern.

If the user wishes to use a different index pattern, instead of documenting the permissions required for the new role that they should be creating, could we better document the workflow: get role - change index pattern - put new role - update native users to use new role - update role mappings to use new role ?

For this to work smoothly we would probably need to implement ways to get users and role mappings by the role name.