[ResponseOps] Granting kibana_system role access to the cases analytics indices

[adcoelho]

Summary

The ResponseOps team is currently working on creating(and populating) dedicated cases analytics indexes during Kibana startup.

This is the feature branch draft PR for reference.

The Kibana System role did not have the privileges needed for this, so in this PR, I added the following:

• .internal.cases*: all - so that the cases analytics indexes can be created/updated/deleted
• cluster:admin/script/put + cluster:admin/script/get - our logic for synchronizing the indexes with the cases' index requires the usage of painless scripts that need to be fetched and updated.

[elasticsearchmachine]

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

[azasypkin]

@elasticmachine update branch

[azasypkin]

The change is aligned with what has been discussed in the relevant RFC and hence LGTM.

I see the scripts we store are static/const, do we plan to compose these scripts dynamically in the near future?

If no, I have a question for @elastic/es-security: is there any precedent where we define a painless script used by some Elastic Stack component (e.g., Kibana) directly in ES so that we don't need to grant cluster:admin/script/put to a service system account to store such a "predefined" script?

[adcoelho]

I see the scripts we store are static/const, do we plan to compose these scripts dynamically in the near future?

The scripts are created statically, but our logic relies on the capacity to create new scripts to handle different Kibana nodes writing to these indexes concurrently.

is there any precedent where we define a painless script used by some Elastic Stack component (e.g., Kibana) directly in ES

If I get your suggestion correctly, this would also complicate our deployment process whenever we want to update mappings and scripts.

[azasypkin]

If I get your suggestion correctly, this would also complicate our deployment process whenever we want to update mappings and scripts.

Assuming it's possible in principle to have predefined scripts in ES, it'd make changes a bit more involved (would require a PR against the ES repo), yes, but I'm not sure if it complicates anything, to be honest, as you won't need to worry about this at Kibana startup and can assume that any given ES version already has the script with the content and ID you need for this version.

That being said, not saying it's better or worse, just exploring alternatives.

[cnasikas]

Thanks @azasypkin for the review and the feedback! To be honest, I am not sure if we will compose the scripts dynamically in the future. We may need to. Aside from that, the sync tasks will have some recovery mechanism to recreate the scripts in case of a catastrophic failure (user tampered with them, for example). We would need the scripts to be part of Kibana to do that, so they can recreate them unless it is implemented on the ES side. Also, when a Kibana node updates the mappings, it also updates the scripts. There is a one-to-one correspondence between the mapping and the scripts. Coordinating ES PRs with Kibana PRs may be challenging. Lastly, I am not sure how ownership works in ES and what the review process is. Do you mind if we move forward with this PR (unless there are security concerns) and explore alternatives after FF? I am open to discussing and seeing what approach makes more sense.

[azasypkin]

Lastly, I am not sure how ownership works in ES and what the review process is.

Same as in Kibana :) For example, AppEx Security co-owns a role definition for the Kibana System user in Elasticsearch and handles reviews, and you'd co-own script definitions (again, if it's possible to do something like this at all - i.e., having ability to define a "built-in/system" script that users cannot mess up with).

Do you mind if we move forward with this PR (unless there are security concerns) and explore alternatives after FF?

Definitely, I've approved the PR, meaning that's not a blocking suggestion, but more of a thing we could potentially explore now or in the future (assuming it has enough benefits from functional, maintenance, and security standpoints).

[cnasikas]

Thanks @azasypkin! Yes, let's explore the alternatives. I would love that.

[slobodanadamovic]

nit: You can reference actual action constants here.

Suggested change

	"cluster:admin/script/put",
	"cluster:admin/script/get",
	TransportPutStoredScriptAction.TYPE.name(),
	GetStoredScriptAction.NAME,