Dynamic Role Creation within Access Workflows

[aelkugia]

Feature Request

A customer shared they don't always have a role defined for all use cases so would like the ability to offer users to request a role based on permissions and create it dynamically for approval.

For example the user defines what they want (get pods, run logs, etc.) and Teleport creates a custom template for the user's specific request (similar to an IAM policy document) and then that role along with the request is submitted for approval.

Once the role is reviewed and approved by an admin the user's role request escalation is granted for a specified period of time. Once the period of time expires the role would also expire (or if it's a role that would be used more frequently then possibly some functionality to allow it to survive).

Motivation

At times the customer is facing situations where the predefined roles do not have the necessary allow or deny permissions needed. Allowing a user to request some specified permissions leading to a dynamic role creation would assist in this situation.

Who's it for?

OSS User, Pro, Enterprise

[stevenGravy]

I could see this being helpful to request access to a particular machine or set of resources.

[klizhentas]

We have this capability right now - folks can script the logic and create role based on arbitrary criteria. Users have to set reason using request_access: reason field in roles and the access workflows plugin can generate the role on the fly.

I would avoid asking users to specify the list of permissions, first of all, it's very verbose, and second, they might not know ahead of time what permissions they need. Instead rely on ticketing system that can connect the issue or ticket number to the set of permissions

[russjones]

Right now you can only see servers you have access to.

We could change Teleport to show you all servers but only enforce RBAC when you try and login. Then this would allow you to request access to a particular resource (like SSH server).

[klizhentas]

@fspmarshall made a good point about my comment above. Right now it's impossible to generate the role on the fly and grant access to it via access requests. Access requests need to know and match roles in advance.

I wonder if that is even the best solution the problem. What problem are customers trying to solve with per-resource access? Let's say Alice asks for access to prod database, what context would Bob have to grant that access? If you have many resources in the system, requesting access per resource will create a lot of noise without necessary context for reviewers.

Instead, we recommend splitting resources by risk class using labels. Then create roles that allow access to a resource by risk class. Then users can request elevated access by a risk class instead of requesting access to individual resources.

This creates a problem for cases when there are many tenants in the system. Creating a role per tenant will lead to too many roles. For such use-cases we recommend automated approval using Jira plugins. A user can have access to production database instance if there is a ticket referring to that tenant that is assigned to a person. This will create a context that is necessary for the org to review the request - the issue, the tenant id and automated approval.

Both of those patterns: labels based access for users and tenant based access by systems already implemented in Teleport. I think we just need to document them better.

@fspmarshall @pschisa @travelton @russjones @xinding33 thoughts?

[fspmarshall]

A strategy that I've been toying with is the idea of allowing limited variables of some kind to be passed through the access request system, to be consumed by variable interpolation within existing roles.

In the "db access within a multi tenant env" example that @klizhentas mentions, a strategy one might employ today would be to use variable interpolation to match a tenant_id label on the database to the values of an allowed_tenants trait. It seems to me that supporting an access request of the form "I would like role tenant-db-access with tenant_id=<some-id>" is a very natural extension of that pattern.

I'm not satisfied with any of the syntax ideas I've come up with so far, but I think the basic idea feels like a very natural extension to how roles and requests currently function.

[pschisa]

Here is a specific use case:

Imagine we already have label based access and these 4 are node labels.

Hostname:
env:
Application:
Owner:

and the user's default role based on their Azure group is as follows.

kind: role
  name: default_role
spec:
     logins:
    - '{{external.username}}'
    node_labels:
        hostname: '*'
        env: '*'
        application: '*'
        owner: '*'
    request:
      roles:
      - Custom-Privileged-Role
  deny: {}

I would like to find a way to make a privileged access request possible based on one of these labels with any ttl on the fly. in order to grant a user the least privileged access possible, or access exactly based on the requirements. Once the role is reviewed and approved by an admin the user's role request escalation is granted for a specified period of time. Once the period of time expires the role would also expire (or if it's a role that would be used more frequently then possibly some functionality to allow it to survive). I'm thinking on something like this:

kind: role
  name: Custom-Privileged-Role-$$
spec:
     logins:
    - root
    node_labels:
        hostname: '$hostname'
        env: '$env'
        application: '$application'
        owner: '$owner'
  deny: {}
  options:
    max_session_ttl: '$ttl'

for these kind of requests:

tsh login teleport-cluster --request-roles=Custom-Privileged-Role  --label="hostname:mysql-001"  --ttl=72h
tsh login teleport-cluster --request-roles=Custom-Privileged-Role  --label="hostname:mysql-001,mysql-002"  -ttl=48h
tsh login teleport-cluster --request-roles=Custom-Privileged-Role --label="hostname:mysql-*11*" --lablel="env=p*" --label="application:*docker*"  #--ttl=2h

[hw-bearrobotics]

Any development plan for this feature? Because this function is very useful for our team. Our team needs an ssh connection to the robot, but the problem is that we can access all the robots at one access request. We should allow only one robot per one access request.

[pschisa]

Will be covered by the implementation of search-based access requests: https://github.com/gravitational/teleport/issues/10887

[zmb3]

This is solved with resource access requests which will be out in Teleport 10.