Scoped Approvals for Access Workflows

[travelton]

Feature Request

EDIT (@klizhentas ): this description has the latest spec

Customer would like define who may approve role requests for a specified role.

Imagine if you had 4 teams/roles configured: dev, qa, dba, admin.

A request from role dev to dba is initiated. Currently, anyone with approval permissions could approve the request. However, this feature request is to limit who can approve the requests for access to the dba role. Users in the dba role should be the approving entity for request into the dba role. The qa team should not have the authority to approve this request.

Add where clause to allow devs to approve roles from their peers, but except themselves

kind: role
metadata:
  name: dev
spec:
  allow:
    request:
      roles: ['dba']
      where: contains(request.annotations, user.traits[team])
  deny:
    approve:
      roles: ['*']
     where: equals(request.user, user.metadata.name)

In this sample, the dev role lets developers to grant access to access requests containing annotations matching their team.

Motivation

Roles are typically built around software or ops teams. These teams should have the ability to grant access to their own infrastructure. This would push the approval process down to the team, and reduce the operational burden of a single team managing approval requests.

Who's it for?

Enterprise

@klizhentas @fspmarshall @travelton updated the description with more detailed spec

[fspmarshall]

I like the sound of this!

Minor Correction:

the dba role permits users of role dev to request access

Other way around actually. Roles always specify the capabilities of the users that hold them, so the above example actually gives dba the ability to request dev. If you want dev to be able to request the dba role, you would specify this as part of the dev role like so:

kind: role
metadata:
  name: dev
spec:
  allow:
    request:
      roles: ['dba']
    # ...

You can basically read the above as: "users with role dev are allowed to request role dba"

Thoughts:

Any new syntax for scoped approvals should probably stick to the "roles define the capabilities of their holders" rule if possible. In the case of the example scenario where access to dba can be approved either by members of dba or members of admin, we'd probably want to end up with something like this:

kind: role
metadata:
  name: dba
spec:
  allow:
    approve:
      roles: ['dba']
    # ...
---
kind: role
metadata:
  name: admin
spec:
  allow:
    approve:
      roles: ['dba']
    # ...

And if we wanted to prevent devs from turning around and granting dba once they themselves were granted it:

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

[travelton]

@fspmarshall Ah yes... Thanks for the correction and clarification in these parts! Your explanation makes perfect sense. I wonder if we could extend this down to the plugins. That would be pretty darn cool to have multi-team/channel approval bots.

[fspmarshall]

I wonder if we could extend this down to the plugins

A plugin is just a nonhuman teleport user... no difference from teleport's perspective. In theory, a lot of plugins could probably work with more limited permissions out of the box (depending on what teleport API methods the plugin calls).

[quodlibetor]

This, in combination with exposing the request/approval workflow from the web UI (the un-scoped version of #4028) would allow me to simplify several parts of my infrastructure.

[klizhentas]

@fspmarshall I think we might not need approve verb, because it is redundant with where scope and verb for access_request resource please check out #4749

[russjones]

Will be addressed in #5071.