Read-only privilege for Security APIs

[albertzaharovits]

Description

Currently there are only a few privileges that grant access to Security-related APIs. manage_security is the main and general one but there are a couple more specilized ones: manage_oidc, manage_api_key, manage_token, manage_service_account and manage_user_profile.
These privileges cover APIs that can view but also change the Security configuration, such as add users, roles, role_mappings.
The ask here is to have a viewer-type of privilege for Security-related APIs, in like manner to the read_slm, read_ilm, read_pipeline and read_ccr or like the monitor_* ones (eg monitor_snapshot) - I prefer read_security.

It should grant access to roughly the following APIs:

• get and query API Keys
• get privileges
• get/suggest profile ? (or maybe not)
• get roles/role mappings/user/user privileges/service accounts
• get SAML metadata

[elasticsearchmachine]

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

[albertzaharovits]

We discussed this today and the team consented that this was a reasonable ask.
Specifically, the use case of an automate process that lists ES users and their permissions, for periodic auditing purposes by a human supervisor, was brought up as the motive.
But before doing any development work, we need input from the product team, ie @bytebilly .

[bytebilly]

I'm in favor of this additional privilege.
Even there is no strong request for it at the moment, it covers valid use cases and shows up from time to time in conversations.

A few questions:

• I suppose that this should be "included" by manage_security and all, but not by other privileges like monitor or manage, is it the current idea?
• would it limit the information that can be retrieved with the same API when you have manage_security privileges?
• I'm not sure if there is a reason to choose monitor_ or read_, do you know how existing privileges were named?

[albertzaharovits]

I suppose that this should be "included" by manage_security and all, but not by other privileges like monitor or manage, is it the current idea?

Yes, that's the plan.

would it limit the information that can be retrieved with the same API when you have manage_security privileges?

I don't think we will need anything like that.
The new privilege will allow access to a subsert of the APIs that the manage_security privilege allows, but will allow "full access" to those APIs. In particular, it should allow viewing all the API Keys, rather than only the API keys that the calling user is the owner off.
Hope, this answers your question.

I'm not sure if there is a reason to choose monitor_ or read_, do you know how existing privileges were named?

It's an unfortunate accident that we have both monitor_ and read_ privileges.
I would think that the monitor_ prefix should be used for APIs that get a status of some job (eg ILM, SLM, watcher), whereas read_ be used for APIs that get the object definition (ILM policy def, role mapping def). But this reasoning is not followed today.
I think we'll have to discuss this topic specifically, ie the difference between read_ and monitor_ privileges, if we want to keep them both going forward, or which should go away, or which should include which or be completely disjointed.

[ywangd]

Based on what we have currently, read_security is better than monitor_security.

I think there is an expectation that all monitor_xxx privileges are covered by the overall monitor one. Implementation wise, most actions covered by monitor_xxx privileges begin with cluster:monitor. The monitor_snapshot is an exception. But based on Albert's reasoning, I think it is a misnomer and should be called read_snapshot (except GetSnapshotStatus which can be part of monitor).

The read_xxx privileges, on the other hand, are mostly begin with cluster:admin which fits better with what we need here (all security actions begin with cluster:admin/xpack/security).

[bytebilly]

Thanks for the additional context, I agree that read_security looks like the right name.

[TaR7k1xPG84]

Hello everyone,

We are the one that submitted the initial support ticket that led to this issue. We're glad that you are open to tackle this one as it is important to us to be able to create roles that are with the least privileges.

The main idea was indeed to have an identical role to manage_security but only with read privileges, so all the same information without the ability to modify them.

We mentionned in the ticket the ability to create roles with specific actions so the need to have access to a list with the API and their required actions, updated and maintained, but that is for another topic.

If we can answer any question that you would have regarding this issue, not code wise of course but product/need wise, we would be happy to answer them.

Thank you for your help!

[albertzaharovits]

I have raised #89790 .