Add monitor and view_index_metadata to built-in kibana_system role

[afharo]

Required for the reimplementation planned of elastic/kibana#64935. Allows the kibana user to collect Data telemetry in a background task by giving the kibana_system reserved role the view_index_metadata and monitoring privileges on *.

[elasticmachine]

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

[ywangd]

IIUC, privileges for 3 actions are required:

• GetIndexAction
• GetMappingsAction
• IndicesStatsAction

view_index_metadata and monitor grant many more privileges than required. Other than the 3 required actions, they also allow following actions:

• GetFieldMappingsAction
• ClusterSearchShardsAction
• GetSettingsAction
• ExplainLifecycleAction
• ValidateQueryAction
• RecoveryAction
• IndicesSegmentsAction
• GetSettingsAction
• IndicesShardStoresAction
• UpgradeStatusAction

We could potentially make new named privileges to get better granularity for the actions. But I am not sure whether it is premature and/or superficial, unless any above actions are expensive or can be easily abused.

Alternatively, I wonder if we could defer this to be a runtime configuration instead of code level. Sorry if this has been discussed already. I may not have the right context here, so I'll let other stack security team members to chime in.

[albertzaharovits]

Thanks for raising the PR, @afharo .

I think the proposed change is relatively benign given that it roughly grants access to index settings and metadata, for all indices, which are already available in the response for GET cluster state, which is permitted under the existing monitor cluster privilege (which kibana-system already has). I also believe we're better off granting the "whole" privileges, as you're proposing in this PR, instead of piece-wise as @ywangd is suggesting, because the named privileges are consistent in the sense that the same information is accessible by different APIs (eg GetFieldMappingsAction and GetMappingsAction).

Since our team meeting is scheduled in a couple of hours, let us have a quick sync on this one, and I'll report back.

[ywangd]

I also believe we're better off granting the "whole" privileges, as you're proposing in this PR, instead of piece-wise as @ywangd is suggesting, because the named privileges are consistent in the sense that the same information is accessible by different APIs (eg GetFieldMappingsAction and GetMappingsAction).

Just to clarify that I was not suggesting granting access for actions directly because it would be against our recommendation. I was wondering whether we could make a new named privilege (e.g. telemetry) or a new role (e.g. telemetry_user) to group relevant actions or privileges, and grant the new privilege or role to kibana.

[afharo]

Thank you both on the updates! I'm sure you'll find the best approach to this. I'll let you discuss it thouroughly. Just let me know if you want me to apply any changes or go on with this one.
Thank you again!

[albertzaharovits]

Just to clarify that I was not suggesting granting access for actions directly because it would be against our recommendation. I was wondering whether we could make a new named privilege (e.g. telemetry) or a new role (e.g. telemetry_user) to group relevant actions or privileges, and grant the new privilege or role to kibana.

Apologies Yang for disregarding your suggestion in the above.
My opinion is that view_index_metadata and monitor grant more privileges than necessary, as is usually the case with asks like these, but that it's not an issue because the bundled actions expose the same information in a different form (eg GetFieldMappingsAction and GetMappingsAction), a subset of the information presented by other actions (eg IndicesStatsAction and IndicesSegmentsAction), or just information that semantically belongs together and there's no practical risk justifying breaking a privilege into slight variations of itself (generally my bias in this case is against a long list of privileges because that increases the burden on the administrator, which might be tempted to "add privileges until it finally works" instead of taking the time to understand each and every privilege).

Of course discussions to reform the privileges structure doesn't have to hold this PR, so I would say we can merge this and discuss breaking the monitor and view_index_metadata privileges with another occasion.

@ywangd would you agree with this course of action?

[ywangd]

@albertzaharovits Your analysis sounds right to me. Thanks for taking time to go through your reasoning.

[albertzaharovits]

@elasticmachine update branch