[Security] Add entity store and asset criticality index privileges to built in roles

[opauloh]

Summary

Currently, the editor and viewer built-in roles do not contain the appropriate Entity Store and Asset Criticality index privileges for Security users.

This PR updates the index privileges to include the .entities.v1.latest.security* and .asset-criticality.asset-criticality-* indices with the appropriate permission:

Viewer

• Read .entities.v1.latest.security*
• Read .asset-criticality.asset-criticality-*

Editor

• Read .entities.v1.latest.security* (Users don't write directly at entity store indices)
• Write .asset-criticality.asset-criticality-*

Kibana system

• Write `.entities.v1.latest.security*

[elasticsearchmachine]

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

[elasticsearchmachine]

Hi @opauloh, I've created a changelog YAML for you.

[richard-dennehy]

Could we have a little more context on this?

This appears to grant access to all security entities and asset criticality indices across all spaces, is this definitely what we want?

Does this need to go into 9.1? The feature freeze is today

[richard-dennehy]

Just to double check - Serverless Editor appears to have write access to these indices - is this difference intentional?

[opauloh]

Thanks for bringing it to my attention!

I will tag @hop-dev and @jaredburgettelastic to help on that. Mark / Jared, from what I could see, users don't really need to write directly into the Entity Store index, but do you happen to know a use case where they would need? Like running the API to clean the Entity Store or something else?

[hop-dev]

No I think this was a mistake in the original PR apologies!

[opauloh]

Thanks for confirming @hop-dev, so @richard-dennehy, the changes on this PR are correct, we will follow up on reducing the extra permissions on Serverless editor role to keep it consistent!

[hop-dev]

@opauloh sorry I have just thought, because the transform runs as the user who enabled the entity store, I believe we do need write permissions? Have I got that wrong?

[opauloh]

I initially thought the same, but it turns out the Transform API doesn't require write privilege.

Required authorization
Index privileges: create_index,read,index,view_index_metadata
Cluster privileges: manage_transform

I guess the rationale behind this is that users shouldn't be writing to the transform destination indices directly anyway?

---

That's also accurate with the Entity Store permission page. (No write access required to the .entities.v1.latest.* index)

Also, by design, Editors wouldn't have the "manage" privilege, so Editors users won't likely be the ones to enable Entity Store / Asset Inventory, unless extra permissions are granted:

I.e screenshot from the permissions screen when accessing the Entity Store with an Editor user:

However, editors should be able to read entity store data and update asset criticality once it's enabled.

---

The only use case I can imagine writing directly would be handy is, if we had to update data directly on the destination index using the user permission to update data without waiting for the transforms to run, however, I didn't find anything performing that operation.

[hop-dev]

Thanks for the detailed investigation, that's interesting about the transform write permissions! 👍

[opauloh]

Could we have a little more context on this?

This appears to grant access to all security entities and asset criticality indices across all spaces, is this definitely what we want?

Yes, the Entity Store and Asset Inventory features are cross-space functionality, and built-in roles should have access to them as they have the Kibana "All spaces" permission by default.

Does this need to go into 9.1? The feature freeze is today

Not necessarily, the main reason to include it now was to grant users less friction access to the new "Asset Inventory" feature in Kibana that's releasing on 9.1, which relies on Asset Criticality and Entity Store that were released in previous versions, however, since Inventory will be in Technical Preview for 9.1 is not mandatory to include the permissions, but it will be for 9.2 when the "Asset Inventory" features goes GA.

[kc13greiner]

Heya @opauloh !

I see you're changing the kibana_system user's privileges on .entities.v1.latest.security from read to all

Just a couple questions:

• Can you provide additional context about "the editor and viewer built-in roles" but not why the kibana_system user's roles need to be updated?
• Is all absolutely necessary? Is there a subset of privileges granted by all that will work instead?

[opauloh]

Hi @kc13greiner, thanks for those questions

Can you provide additional context about "the editor and viewer built-in roles" but not why the kibana_system user's roles need to be updated?

Sure, I will use the user Entity store to exemplify. User entity store source it's data from multiple indices, which are processed by a pivot transform where outputs the aggregated data into the final index .entities.v1.latest.security_user_default.

In this scenario, Editor users of the Entity Store experience wants to have the ability to change the Criticality and Risk scoring, and for this it's needed write permission to the risk-score.risk-score-latest-default and .asset-criticality.asset-criticality-default. Write permission in the .entities.v1.latest.security_user_default index is not needed and even discouraged for the user, since the transform will take care of updating the final index once the transform is processed.

Why add 'write' permission to the `.entities.v1.latest.security index to the Kibana System and not to Editor / Viewer?*

We started to improve the UX for the users, users visualize data directly from .entities.v1.latest.security_user_default, so as you can imagine, changing some field, i.e (Asset Criticality) and having to wait for a couple of minutes to see this update reflected in the interface is not ideal. The solution we came up with is that, once the asset_criticality API successfully creates/update/delete a record in the .asset-criticality.asset-criticality-default index, it will also be responsible for updating the record directly in the final index (.entities.v1.latest.security_user_default). Our conclusion is that updating the final index should be considered an internal operation, so users still keep the granular control when creating roles with write access. For example, a user who only needs to change Asset Criticality will require only write permission for .asset-criticality; they shouldn't need to have write permission to the .entities.v1.latest.security_user_default for that purpose.

Is all absolutely necessary? Is there a subset of privileges granted by all that will work instead?

Good point! After reviewing it, all we need for the mentioned improvement is to add "write" permission on top of the "read" permission, I will update it accordingly, the idea of granting "all" was to prepare for future use cases that are in discussion like migration and backfilling of Entity Store data, this means we will surely need extra permissions when the time comes, but unlike the use case above we don't know exactly when, so I agree it's a safer choice to add more permissions as needed and only the exact required permissions.

[opauloh]

cc @kc13greiner, forgot I had auto-merged enabled, so it merged as soon as I updated the permission. Let me know if everything is clear

[kc13greiner]

@opauloh

Thank you for the excellent overview! I agree that it makes sense in this case to add write on that system index.

And thanks for dialing back all to write! That is much preferred from a security standpoint 🚀

LGTM!