Add approval scopes

[klizhentas]

Feature Request

For RBAC in approval workflows, here is a current way to provide user access to grant
access to the access_requests:

kind: role
version: v3
metadata:
  name: access_request_grantor
spec:
  # SSH options used for user sessions 
  options:

  # allow section declares a list of resource/verb combinations that are
  # allowed for the users of this role. by default nothing is allowed.
  allow:
    logins: ['this-login-does-not-exist']

    rules:
    - resources:
      - access_request
         verbs: [list, read, update]


  # the deny section uses the identical format as the 'allow' section.
  # the deny rules always override allow rules.
  deny:
    
    node_labels:
      '*': '*'

Where clause adds ability to limit the scope of approval, but we have to make sure it's supported for this resource in the implementation:

kind: role
version: v3
metadata:
  name: access_request_grantor
spec:
  # SSH options used for user sessions 
  options:

  # allow section declares a list of resource/verb combinations that are
  # allowed for the users of this role. by default nothing is allowed.
  allow:
    logins: ['this-login-does-not-exist']

    rules:
    - resources:
      - access_request
         verbs: [list, read, update]
         where: contains(resource.metadata.labels, "dev")

See implementation and tests for where clause here

[benarent]

I like this proposal it's a good use and example for using where:, having full CRUD is powerful, but I wonder if we could have an alias for a collection of actions. e.g. verbs: [approver/requestor].. also for a pure approver, Do the need the create verb?

[klizhentas]

we don't need create verb, removed it from the example

[travelton]

If I understand this issue, the goal is to scope approval of role escalation to resources that contain a specific tag?

Here's an example:

I have three teams using Teleport; ops, devs, dbas.

devs have the ability to approve access_request from dbas to devs. However, devs should not have the ability to approve an access_request from ops to dbas.

Could we simplify this by defining the config via yaml? So in the following case, an additional approve key under allow would permit the devs role to request dba role and approve access requests for devs role requests only.

kind: role
metadata:
  name: devs
spec:
  options:
    # ...
  allow:
    request:
      roles: ['dba']
    approve:
      roles: ['devs']
    # ...
  deny:
    # ...

[webvictim]

@travelton I think the scope of the issue is slightly different to what you're requesting here.

[klizhentas]

dupe of #4749