Meta: Adjust privilege levels in Security

[elasticmachine]

Original comment by @tvernum:

The current set of pre-defined privileges is quite coarse and we have a number of open issues requesting that we look at changing that.

This is meta issue for trying to collect those in one place for tracking and evaluation.

[elasticmachine]

Original comment by @tvernum:

index:manage

• force merge : Add index-level privilege for force merge #29702
• manage_aliases, manage_templates and open_close_indices: Add manage_aliases, manage_templates and open_close_indices as separate privileges #29732
• refresh / flush: Add index privilege for refresh/flush separate to manage  #29998

cluster:manage

• snapshot / restore : Add Cluster-level Privilege for Managing Snapshot/Restore #29725
• license: Licensing role #29971
• scripts: Add minimal privilege to manage stored scripts #48476

cluster:manage_security

• user editing privileges : More granular user editing privileges #29932
• readonly security: Add security_read cluster privilege #29999

cluster:pipeline

• allow read & simulate without put: Security privileges for ingest pipelines #57586

[elasticmachine]

Original comment by @albertzaharovits:

I wonder if we could could make the cluster:admin/settings/update privilege more fine grained.
Specifically, the privilege could be read/write for a namespace of settings, similar to the indices privilege.
Thoughts ?

[elasticmachine]

Original comment by @tvernum:

@albertzaharovits it sounds like you're talking about Object Level Security.

[elasticmachine]

Original comment by @albertzaharovits:

@tvernum kind of... A restricted version of it, where objects are setting keys. I have yet to internalize the OLS opus.
I am dreaming of a new type of privilege, for settings only.
I should probably go read the OLS manual.

[elasticmachine]

Original comment by @gmoskovicz:

I love to see this coming back.

[elasticmachine]

Original comment by @jaymode:

I love to see this coming back.

@gmoskovicz what's coming back? We're not talking about documenting action names and how to use them in roles as part of this issue.

[elasticmachine]

Original comment by @gmoskovicz:

In previous discussions my understanding was that we considered not exposing this any more. So removing the option to use them. With this additions, it seems to be that we are not removing them, regardless of not documenting action names.

Although to be honest, i think documenting them might be a good option as well.

[elasticmachine]

Original comment by @jaymode:

With this additions, it seems to be that we are not removing them, regardless of not documenting action names.

This issue is about adding more granular items like a open_close_indices privilege, which has nothing to do with action names in roles from a user facing perspective. Its not safe to assume this means we will not remove the ability to authorize at the action level in the future based on this issue.

[elasticmachine]

Original comment by @gmoskovicz:

I would encourage not to remove the action level authorizations. With x-pack security, i can say that a huge number of users are using it, and removing it unexpectedly will be a huge miss for them.

Also, the context of this issue seems to be related to redefine or add/change pre-defined privileges, which to me is completely related to the granular action names as they are used in the same context and configuration. While i understand your statement, from a user perspective, both are the same.

[elasticmachine]

Original comment by @astefan:

@jaymode I can, also, say for sure that some users do use the granular permissions. I know they are not documented now but they were in the past and some "re-used" them somehow or, if they do have development background, can have a look inside x-pack decompiled code for example.

And, to be honest, I've heard of requests where they were asking questions about permissions that were only possible with the granular permissions.

If there are previous requests somewhere recorded to bring back the granular permissions (in the documentation of course), I'd +100 to those requests.

[elasticmachine]

Original comment by @jaymode:

There have been requests to bring the action level privileges back (ie re-document all of them and how to use them) back but what is missing is understanding why action level privileges do not make sense for the future of elasticsearch. Today we authorize at the action level but the majority of users do not know about actions nor should they; they think of elasticsearch in terms of APIs and the future will be rest only from a client perspective.

There is no 1:1 mapping for rest to action privileges. Go back and look at all the random issues people had with shield because they thought they had all the action privileges they needed but then used a different parameter in a request and things broke. This is not a good user experience.

From a mindset perspective, we need to move away from thinking that bringing back action level privileges will be the way to achieve granular permissions. Instead, we need to think about operations in elasticsearch and how users interact with it. So while some of the more granular privileges mentioned in this issue could map directly to an action, others will map to many different actions.

[elasticmachine]

Original comment by @gmoskovicz:

Thanks for your answer @jaymode !

There have been requests to bring the action level privileges back (ie re-document all of them and how to use them) back but what is missing is understanding why action level privileges do not make sense for the future of elasticsearch. Today we authorize at the action level but the majority of users do not know about actions nor should they; they think of elasticsearch in terms of APIs and the future will be rest only from a client perspective.

I think that until all the use cases, and the options to define privileges without actions, aren't included in a way that it is flexible enough to make sure you can define any set of specific user roles with specific actions, documenting the granular actions is a good idea. Even if we deprecate them in the future to finally remove them when we have all options available.

There is no 1:1 mapping for rest to action privileges. Go back and look at all the random issues people had with shield because they thought they had all the action privileges they needed but then used a different parameter in a request and things broke. This is not a good user experience.

Correct, although right now the only option to achieve some specific user roles is to (unfortunately) use action level privileges.

From a mindset perspective, we need to move away from thinking that bringing back action level privileges will be the way to achieve granular permissions. Instead, we need to think about operations in elasticsearch and how users interact with it. So while some of the more granular privileges mentioned in this issue could map directly to an action, others will map to many different actions.

In this, i completely agree. But before we are there, we need to provide both options. The action level privileges will allow advanced use cases that requires in depth knowledge of how these things work, while the API privileges or group of actions bundled inside a privilege will allow anyone to start using security.

Once we evolve, we could deprecate/remove the action levels, to just provide the group of actions.

[elasticmachine]

Original comment by @jaymode:

Correct, although right now the only option to achieve some specific user roles is to (unfortunately) use action level privileges.

Can we make sure the team is aware of these roles that require action level privileges? If we know those, then it helps us complete the work for this issue.

[elasticmachine]

Original comment by @astefan:

One example: LINK REDACTED

[elasticmachine]

Original comment by @jaymode:

@costin also raised that our current SQL documentation defines an example role using action level privileges for two things. The first is accessing the / rest endpoint and the second is a call to get index.

cli_or_jdbc_minimal:
  cluster:
    - "cluster:monitor/main"
  indices:
    - names: test
      privileges: [read, "indices:admin/get"]
    - names: bort
      privileges: [read, "indices:admin/get"]