Resource permission management

[peternied]

Description

With resource based permissions for views, the authorization system within the Security Plugin will need to handle requests that provide resource type / id data against the security roles. How these grants are written has an impact on the administrative user experience.

This issue contains an initial proposal built in a proof of concept, but is not hard requirements for the feature.

[Proposal 1] Resource Permission Grants

With requests include resource type and identifiers the security plugin will need to allow for grants to these new types. Modify the security role to include this information under a section resource_permissions so it can be checked and then the request can be permitted.

all_access:
  reserved: true
  hidden: false
  static: true
  description: "Allow full access to all indices and all cluster APIs"
  cluster_permissions:
    - "*"
  index_permissions:
    - index_patterns:
        - "*"
      allowed_actions:
        - "*"
  tenant_permissions:
    - tenant_patterns:
        - "*"
      allowed_actions:
        - "kibana_all_write"
  resource_permissions:
    - resource_type: "view"
      resource_ids: ["songs", "albums"]

Exit Criteria

• Update to the security configuration for new resource section

[cwperks]

@peternied Does the new permission section also need allowed_actions as well? i.e. User can search on views x, y and z? How would permission to create or delete views be handled? Will it be similar to how indices work today?

Does the resource_ids section accept wildcards or are those exact matches only?

[peternied]

@cwperks Thanks for the questions

Does the new permission section also need allowed_actions as well?

I avoided adding allowed_actions as I had a hard time thinking of how to express these in a way that wouldn't become hard to read given either 1) a lot of different resources and 2) a lot of different actions that can be applied to those resources. Ways that I was considering would require sorting/ordering of values so its easy to find items. I figure a simpler approach could be expanded after time.

To your question specifically, for the permission calculation in the prototype I used is Rest/Transport action name allowed && is the resource id in the list of allowed items. While this prevents granular this or that kinds of permissions in a single role, maybe multiple roles is the better solution than making a single role support the more complex matrix with the traditional cluster permissions.

Example roles

read_only_view:
  cluster_permissions:
    - cluster:views:list
    - cluster:views:get
    - cluster:views:search
  resource_permissions:
    - resource_type: view
      resource_ids: ["songs", "albums"]

read_write_views:
  cluster_permissions:
    - cluster:views:search
    - cluster:views:list
    - cluster:views:create
    - cluster:views:get
    - cluster:views:delete
    - cluster:views:update
  resource_permissions:
    - resource_type: view
      resource_ids: ["*"]

Note: if you can create views its strange not to have wildcard resource access

[peternied]

Does the resource_ids section accept wildcards or are those exact matches only?

* is special - for match all. I do not support wildcard matches of identifiers with the prototype. While allowing * is pretty trivial I figured I would start with a limited a vocabulary and build up with strong justifications.

My concern about wildcard matches is that it is too easy to create something and unexpected people have permissions because of a poorly constructed match string. When the only options are specific vs everything its much easier to interpret an access control list from a glance.

[stephen-crawford]

[Triage] Hi @peternied, thank you for filing this issue. This is a RFC so we can mark this triaged and label as help wanted (for community input).