Adding GET/PUT ILM cluster privileges to kibana_system role

[legrego]

Resolves #46894

As outlined in #46894, the kibana_system role needs the ability to retrieve and create ILM policies. Additionally, it needs to be able to assign these policies to indices matching the .kibana* pattern.

Since kibana_system can already do everything against .kibana*, the latter is already taken care of. This PR addresses the former by granting the appropriate cluster privileges to the kibana_system role.

[elasticmachine]

Pinging @elastic/es-security (:Security/Authorization)

[kobelb]

Looks good to me, but I ultimately defer to @elastic/es-security. I don't know of a way to accomplish what @albertzaharovits suggested here...

[albertzaharovits]

Thanks for raising this @legrego ! We'll be discussing this at our next team meeting. I am particularly worried that the kibana_system can now manipulate all the policies and add the delete action, thereby deleting all the indices that have a policy assigned.

[albertzaharovits]

We've discussed and raised #50130 as a consequence.

[albertzaharovits]

@pmuellr May I ask you to name the ILM policy and not change its name? We plan to introduce a new privilege so that kibana_system can manipulate only a namespace subset of ILM policies.

[albertzaharovits]

LGTM, provided we'll have to revise this when we introduce a new privilege, possibly not before the next minor release.

[legrego]

May I ask you to name the ILM policy and not change its name? We plan to introduce a new privilege so that kibana_system can manipulate only a namespace subset of ILM policies.

Would it be ok if the policy had a known unchangeable prefix, but a customizable suffix? We'll need to support multi-tenant Kibana setups, so if users have multiple .kibana indices in the same cluster, I imagine we'll also need multiple ILM policies to manage the different indices we'd create for alerting's event log.

We do something similar today with the application privileges Kibana registers with Elasticsearch.

[pmuellr]

Would it be ok if the policy had a known unchangeable prefix, but a customizable suffix? We'll need to support multi-tenant Kibana setups, so if users have multiple .kibana indices in the same cluster, I imagine we'll also need multiple ILM policies to manage the different indices we'd create for alerting's event log.

Larry is correct - the name of the ES resources for the new event log are all prefixed with the "kibana index name" (default: .kibana), to accommodate multi-tenant scenarios. The ILM policy is something like {kibana-index-name}-event-log-ilm-policy, so the default would be .kibana-event-log-ilm-policy.

My understanding is these multi-tenant scenarios require some amount of additional admin work by the customer to set up correctly - new roles need to be created, etc for the new "alternative" kibana indices. Adding some additional work by the customer to accommodate a new policy for the ILM bits seems like it would be ok.

[kobelb]

My understanding is these multi-tenant scenarios require some amount of additional admin work by the customer to set up correctly - new roles need to be created, etc for the new "alternative" kibana indices. Adding some additional work by the customer to accommodate a new policy for the ILM bits seems like it would be ok.

Customers are able to exploit the fact that kibana_system has access to .kibana* and change their kibana.index to something like .kibana_marketing without having to create custom users/roles at the moment.

[legrego]

@elasticmachine merge upstream

[legrego]

@elasticmachine merge upstream