Determine if user has any application privileges

[kobelb]

The current _has_privileges API requires a list of actions/privileges to check at a specific set of resources. This makes it difficult to determine if the user has any privileges for a specific application, as the consumer is required to provide a list of all potential resources.

When discussing with @tvernum, he mentioned the potential of expanding the _has_privileges API to support this or creating a new API to get a user's privileges for a specific application.

[elasticmachine]

Pinging @elastic/es-security

[tvernum]

I have a prototype of how this could work within _has_privileges here: https://github.com/tvernum/elasticsearch/tree/app-priv/any-resource

If the resources array is null, it will be implied to be the set of resources that have been granted to the user.

[tvernum]

I now also have a prototype of a brand new API GET /_xpack/security/user/_privileges
https://github.com/tvernum/elasticsearch/tree/list-privileges

This returns a user's full set of privileges with 2 caveats:

1. It doesn't attempt to represent the conditions on "global" privileges. e.g. It will claim that the kibana user has the cluster:admin/xpack/security/privilege/* cluster privilege, even though it actually only has that for some applications.
2. It intentionally doesn't (and can't/won't) expand out the privileges, so if you have "all" then it returns "all" and doesn't list "read", "write", "delete", "update" etc.

Per my commit message, this API should only be used for 2 broad purposes:

1. general debugging. It will come in handy operationally, to be able to ask "what privileges does this user have?" when trying to resolve operational issues. The _authenticate API lists role names, but this goes a step further
2. determining resources for application privileges and/or index privileges. You'd never want to use this (on its own) to try and work out whether a user has "index" access to "metrics-2018-08-30", it would require the client to interpret all the privilege names and their implications, and also expand the wildcards. But it does allow you to do exactly what is being asked for in this issue - find out what resources should be fed into _has_privileges in order to determine if the user has any write access, etc.

[tvernum]

@elastic/es-security - your input is appreciated here.

TL;DR :

• Option 1 : Extend _has_privileges
• Option 2 : Add a new API

---

First a bit of background. @kobelb spoke to me about this a few weeks ago, and we agreed that since ES is now in the business of acting as a security oracle for other stack apps, we need to offer the sorts of APIs that are necessary to do that well. And one of those is a way to find out something along the lines of "Does this user have write access to something in my application?"

_has_privileges can't do that right now, because it always considers wildcards to be exhaustive. That is

has "kibana":"write" on "*" ?

is interpreted as "can the user write to everything"?
There is no way to get that "*" to mean something.

There were 2 broad options for that:

1. change _has_privileges to support some sort of something / anything query
2. create a new API to list the resources that a user did have access to.

I have prototypes the 2 options above (both are "working" prototypes, but neither of them has tests), I prefer the second option, but would like to open it up for discussion.

---

In writing this, I realise that neither option provides a solution a question like "Which spaces can a user write to?", if "write" is a generic privilege that applies to all sorts of entities.
You can ask "Which of these spaces can the user write to?" and "What things can the user write to?" but you can't restrict those things to a subset of resources.
More concretely, there is no API like this:

GET /_xpack/security/user/_privileges
{
   "applications": [
     { 
        "application": "kibana",
        "privileges": [ "write" ],
        "resources": [ "spaces/*" ]
     }
  ]
}

The solution (which is an approach I've already recommened to @kobelb, and IIRC matches their plan) is to not have such generic privilege names. If your privilege is actually "write_space" (or more likely something like spaces:write) then you get some way there because you can then ask "What resources to the user have access to", and then "Does the user have write_space on any of those resources" ?
What you can never get under any API proposal (because it's an impossibility) is a list of all space ids (resources) that the user has access to.
superuser has access to * privileges for * resources on * applications. If you ask which spaces elastic can view, then it's all of them, but how do we represent that? Technically we can perform the Automaton intersection, but returning that result back in an API is impractical and would require that the client interpret some sort of wildcard. And if we're making the client interpret wildcards, then we may as well just let them interpret the API as proposed.

[albertzaharovits]

Here is what I reckon:
The existing _has_privileges works with resource patterns, but the response contains the resource pattern from the request, instead of the actual resources under that pattern that have been checked. (I have not tested because I am hitting some problems with the put privilege call that gets routed to the index call handler). If this is the case, I think we should keep it like this. Even though the response is not very useful, the response "code": granted/denied, is presumably the important part, and it is truthful.

Indeed the requirement to list the resources under an application (under a specified privilege) or the privileges of a set of resources is necessary. Otherwise, who knows what _has_privileges is doing behind ? Testing some unknown stale resources/privileges.

Therefore I think Option2 is desirable. The issue is tied to has privilege but independent enough to warrant a different API call. I do hope clients will not use the new API to duplicate the has privilege logic on the client side 😐

[jaymode]

+1 to option 2 with one request.

It doesn't attempt to represent the conditions on "global" privileges. e.g. It will claim that the kibana user has the cluster:admin/xpack/security/privilege/* cluster privilege, even though it actually only has that for some applications.

I think this should be addressed. We have a way that we represent conditional privileges in a role and I think the output of any API should also indicate that there is a condition on said privilege.

[tvernum]

Based on the feedback above, I have pushed a new version of the list-privileges branch.

The output is now modelled on the Get Role API, but a few fields have become arrays to reflect the way privileges from different roles are merged together at runtime.

@kobelb I trust the output below is more than sufficient for your needs:

{
  "cluster" : [ "monitor", "manage_ml" ],
  "global" : [
    {
      "application" : {
        "manage" : { "applications" : [ "my-app-*", "your-app" ] }
      }
    }
  ],
  "indices" : [
    {
      "names" : [ "abc*" ],
      "privileges" : [ "read" ],
      "field_security" : [
        {
          "grant" : [ "*" ],
          "except" : [ "secret.*" ]
        },
        {
          "grant" : [ "secret.*" ],
          "except" : [ "secret.top" ]
        }
      ],
      "query" : [
        "{ \"match\" : { \"mode\": \"public\" } }",
        "{ \"match\" : { \"mode\": \"shared\" } }"
      ]
    }
  ],
  "applications" : [
    {
      "application" : "kibana",
      "privileges" : [ "read" ],
      "resources" : [ "data/foo/*",  "*" ]
    },
    {
      "application" : "kibana",
      "privileges" : [ "*" ],
      "resources" : [ "data/foo/*" ]
    },
    {
      "application" : "kibana",
      "privileges" : [ "write" ],
      "resources" : [ "data/foo/*", "user/_self" ]
    }
  ],
  "run_as" : [ "user1", "user-*" ]
}

[kobelb]

This works for us, thanks @tvernum