Fork me on GitHub

Teleport

Resource Access Requests

Improve
Preview

Resource Access Requests are currently in Preview.

With Teleport Resource Access Requests, users can request access to specific resources without needing to know anything about the roles or RBAC controls used under the hood. The Access Request API makes it easy to dynamically approve or deny these requests.

Just-in-time Access Requests are a feature of Teleport Enterprise. Open-source Teleport users can get a preview of how Access Requests work by requesting a role via the Teleport CLI. Full Access Request functionality, including Resource Access Requests and an intuitive and searchable UI are available in Teleport Enterprise.

Prerequisites

  • A running Teleport Enterprise cluster, including the Auth Service and Proxy Service. For details on how to set this up, see our Enterprise Getting Started guide.

  • The Enterprise tctl admin tool and tsh client tool version >= 13.0.3, which you can download by visiting your Teleport account.

    tctl version

    Teleport Enterprise v13.0.3 go1.20

    tsh version

    Teleport v13.0.3 go1.20

Cloud is not available for Teleport v.
Please use the latest version of Teleport Enterprise documentation.
  • Make sure you can connect to Teleport. Log in to your cluster using tsh, then use tctl remotely:
    tsh login --proxy=teleport.example.com [email protected]
    tctl status

    Cluster teleport.example.com

    Version 13.0.3

    CA pin sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

    You can run subsequent tctl commands in this guide on your local machine.

    For full privileges, you can also run tctl commands on your Auth Service host.

Warning

All teleport instances in the cluster must be running Teleport v10.0.0 or greater in order for Resource Access Requests to be properly enforced. Older versions of teleport will only do RBAC checks based on roles and will not respect resource restrictions. It is not recommended to enable Resource Access Requests by setting any search_as_roles until all teleport instances in your cluster have been upgraded to version 10.

Step 1/8. Create the requester role

This role allows the requester to search for resources accessible by the access role (all resources by default) and request access to them.

# requester.yaml
kind: role
version: v5
metadata:
  name: requester
spec:
  allow:
    request:
      search_as_roles:
        - access
tctl create requester.yaml

Step 2/8. Create the reviewer role

This role allows the reviewer to approve all requests for the access role.

# reviewer.yaml
kind: role
version: v5
metadata:
  name: reviewer
spec:
  allow:
    review_requests:
      roles:
        - access
      preview_as_roles:
        - access
tctl create reviewer.yaml

Step 3/8. Grant the roles to users

Grant the requester and reviewer roles to existing users, or create new users to test this feature. Make sure the requester has a valid login so that they can view and access SSH nodes.

tctl users add alice --roles requester --logins alice
tctl users add bob --roles reviewer

For the rest of the guide we will assume that the requester role has been granted to a user named alice and the reviewer role has been granted to a user named bob.

Step 4/8. Search for resources

First, log in as alice.

tsh login --proxy teleport.example.com --user alice

Notice that tsh ls returns an empty list, because alice does not have access to any resources by default.

tsh ls

Node Name Address Labels

--------- ------- ------

Then try searching for all available ssh nodes.

tsh request search --kind node

Name Hostname Labels Resource ID

------------------------------------ ----------- ------------ ------------------------------------------------------

b1168402-9340-421a-a344-af66a6675738 iot test=test /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738

bbb56211-7b54-4f9e-bee9-b68ea156be5f node test=test /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f

To request access to these resources, run

> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \

--reason <request reason>

You can search for resources of kind node, kube_cluster, pod, db, app, and windows_desktop. Advanced filters and queries are supported. See our filtering reference for more information.

Try narrowing your search to a specific resource you want to access.

tsh request search --kind node --search iot

Name Hostname Labels Resource ID

------------------------------------ ----------- ------------ ------------------------------------------------------

b1168402-9340-421a-a344-af66a6675738 iot test=test /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738

To request access to these resources, run

> tsh request create --resource /teleport.example.com/node/b1168402-9340-421a-a344-af66a6675738 \

--reason <request reason>

Step 5/8. Request access to a resource

Copy the command output by tsh request search in the previous step, optionally filling in a request reason.

tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \ --reason "responding to incident 123"

Creating request...

Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab

Username: alice

Roles: access

Resources: ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]

Reason: "responding to incident 123"

Reviewers: [none] (suggested)

Status: PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

Waiting for request approval...

The command will automatically wait until the request is approved.

Step 6/8. Approve the Access Request

First, log in as bob.

tsh login --proxy teleport.example.com --user bob

Then list, review, and approve the Access Request.

tsh request ls

ID User Roles Resources Created At (UTC) Status

------------------------------------ ----- ------ --------------------------- ------------------- -------

f406f5d8-3c2a-428f-8547-a1d091a4ddab alice access ["/teleport.example.... [+] 23 Jun 22 18:25 UTC PENDING

[+] Requested resources truncated, use `tsh request show <request-id>` to view the full list

hint: use 'tsh request show <request-id>' for additional details

use 'tsh login --request-id=<request-id>' to login with an approved request

tsh request show f406f5d8-3c2a-428f-8547-a1d091a4ddab

Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab

Username: alice

Roles: access

Resources: ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]

Reason: "responding to incident 123"

Reviewers: [none] (suggested)

Status: PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

tsh request review --approve f406f5d8-3c2a-428f-8547-a1d091a4ddab

Successfully submitted review. Request state: APPROVED

Check out our Access Request Integrations to notify the right people about new Access Requests.

Step 7/8. Access the requested resource

alice's tsh request create command should resolve now that the request has been approved.

tsh request create --resource /teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f \ --reason "responding to incident 123"

Creating request...

Request ID: f406f5d8-3c2a-428f-8547-a1d091a4ddab

Username: alice

Roles: access

Resources: ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]

Reason: "responding to incident 123"

Reviewers: [none] (suggested)

Status: PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

Waiting for request approval...

Approval received, getting updated certificates...

> Profile URL: https://teleport.example.com

Logged in as: alice

Active requests: f406f5d8-3c2a-428f-8547-a1d091a4ddab

Cluster: teleport.example.com

Roles: access, requester

Logins: alice

Kubernetes: disabled

Allowed Resources: ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]

Valid until: 2022-06-23 22:46:22 -0700 PDT [valid for 11h16m0s]

Extensions: permit-agent-forwarding, permit-port-forwarding, permit-pty

alice can now view and access the node.

tsh ls

Node Name Address Labels

--------- --------- ---------

iot [::]:3022 test=test

iot:~ alice$

Step 8/8. Resume regular access

While logged in with a Resource Access Request, users will be blocked from access to any other resources. This is necessary because their certificate now contains an elevated role, so it is restricted to only allow access to the resources they were specifically approved for. Use the tsh request drop command to "drop" the request and resume regular access.

tsh request drop

Next Steps

Automatically request access for SSH

Once you have configured Resource Access Requests, tsh ssh is able to automatically create a Resource Access Request for you when access is denied, allowing you to skip the tsh request search and tsh request create steps.

ERROR: access denied to alice connecting to iot on cluster teleport.example.com

You do not currently have access to [email protected], attempting to request access.

Enter request reason: please

Creating request...

Request ID: ab43fc70-e893-471b-872e-ae65eb24fd76

Username: alice

Roles: access

Resources: ["/teleport.example.com/node/bbb56211-7b54-4f9e-bee9-b68ea156be5f"]

Reason: "please"

Reviewers: [none] (suggested)

Status: PENDING

hint: use 'tsh login --request-id=<request-id>' to login with an approved request

Waiting for request approval...

Approval received, reason="okay"

Getting updated certificates...

iot:~ alice$

Restrict the resources a user can request access to

In this guide, we showed you how to enable a user to search for resources to request access to. To do so, we assigned the user a Teleport role with the search_as_roles field set to the preset access role.

You can impose further restrictions on the resources a user is allowed to search by assigning search_as_roles to a more limited role. Below, we will show you which permissions you must set to restrict a user's ability to search for different resources.

To restrict access to a particular resource using a role similar to the ones below, edit one of the user's roles so the search_as_roles field includes the role you have created.

node

You can restrict access to searching node resources by assigning values to the node_labels field in the spec.allow or spec.deny fields. The following role allows access to SSH Service instances with the env:staging label.

kind: role
version: v5
metadata:
  name: staging-access
spec:
  allow:
    node_labels:
      env: staging
    logins:
      - "{{internal.logins}}"
  options:
    # Only allows the requester to use this role for 1 hour from time of request.
    max_session_ttl: 1h

kube_cluster

You can restrict access to searching kube_cluster resources by assigning values to the kubernetes_labels field in the spec.allow or spec.deny fields.

The following role allows access to Kubernetes clusters with the env:staging label:

kind: role
metadata:
  name: kube-access
version: v6
spec:
  allow:
    kubernetes_labels:
      'env': 'staging'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "*"
  deny: {}

pod

You can restrict access to pod resources by assigning values to the kubernetes_resources field in the spec.allow or spec.deny fields.

The following role allows access to Kubernetes pods with the name nginx in any namespace, and all pods in the dev namespace:

kind: role
metadata:
  name: kube-access
version: v6
spec:
  allow:
    kubernetes_labels:
      '*':'*'
    kubernetes_resources:
      - kind: pod
        namespace: "*"
        name: "nginx*"
      - kind: pod
        namespace: "dev"
        name: "*"
    kubernetes_groups:
      - viewers
  deny: {}
Access Requests for pods

Teleport users can request access to a Kubernetes pod by running the following command:

tsh request create pod-id

Replace pod-id with the name of a pod in the following format:

/TELEPORT_CLUSTER/pod/KUBE_CLUSTER/NAMESPACE/POD_NAME

For example, to request access to a pod called nginx-1 in the development namespace, run the following command:

tsh request create --resources /teleport.example.com/pod/mycluster/development/nginx-1

For the NAMESPACE and POD_NAME values, you can match ranges of characters by supplying a wildcard (*) or regular expression. Regular expressions must begin with ^ and end with $.

For example, to create a request to access all pods in all namespaces that match the regular expression /^nginx-[a-z0-9-]+$/, run the following command:

tsh request create --resources /teleport.example.com/pod/mycluster/*/^nginx-[a-z0-9-]+$

If a user has no access to a Kubernetes cluster, they can search the list of pods in the cluster by running the following command:

tsh request search --kind=pod --kube-cluster=kube-cluster \[--kube-namespace=namespace|--all-kube-namespaces]

Name Namespace Labels Resource ID

----------------- --------- --------- ----------------------------------------------------------

nginx-deployment-0 default app=nginx /teleport.example.com/pod/local/default/nginx-deployment-0

nginx-deployment-1 default app=nginx /teleport.example.com/pod/local/default/nginx-deployment-1

To request access to these resources, run

> tsh request create --resource /teleport.example.com/pod/local/default/nginx-deployment-0 --resource /teleport.example.com/pod/local/default/nginx-deployment-1 \

--reason <request reason>

The list returned includes the name of the pod, the namespace it is in, its labels, and the resource ID. Pods included in the list are those that match the kubernetes_resources field in the user's search_as_roles. The user can then:

  • Request access to the pods by running the command provided by the tsh request search command.
  • Edit the command to request access to a subset of the pods.
  • Use a custom request with wildcards or regular expressions.

tsh request search --kind=pod works even if the user has no permissions to interact with the desired Kubernetes cluster, but the user's search_as_roles values must allow access to the cluster. If the user is unsure of the name of the cluster, they can run the following command to search it:

tsh request search --kind=kube_cluster

Name Hostname Labels Resource ID

----- -------- ------ ----------------------------------------

local /teleport.example.com/kube_cluster/local

Preventing unintended access

If you are setting up a Teleport role to enable just-in-time access to a specific Kubernetes pod, you should set the role's kubernetes_groups and kubernetes_users to a role that has no access to Kubernetes resource beside the target pod.

This is because, if a user requests access to a Kubernetes pod, and the request is approved, the Teleport Kubernetes Service will use the kubernetes_groups and kubernetes_users fields in the role to add impersonation headers to the user's requests to a Kubernetes API server.

If the values of kubernetes_users and kubernetes_groups map to Kubernetes users and groups with access to additional resources, the user will be able to send requests that interact with those resources, e.g., Secrets and ConfigMaps, depending on the privileges of the Kubernetes users and groups.

db

You can restrict access to searching db resources by assigning values to the db_labels field in the spec.allow or spec.deny fields.

The following role allows access to databases with the environment:dev or environment:stage labels:

kind: role
version: v5
metadata:
  name: developer
spec:
  allow:
    db_labels:
      environment: ["dev", "stage"]

    # Database account names this role can connect as.
    db_users: ["viewer", "editor"]
    db_names: ["*"]

app

You can restrict access to searching app resources by assigning values to the app_labels field in the spec.allow or spec.deny fields.

The following role allows access to all applications except for those in env:prod:

kind: role
version: v5
metadata:
  name: dev
spec:
  allow:
    app_labels:
      "*": "*"
  deny:
    app_labels:
      env: "prod"

windows_desktop

You can restrict access to searching windows_desktop resources by assigning values to the windows_desktop_labels field in the spec.allow or spec.deny fields.

The following role allows access to all Windows desktops with the environment:dev or environment:stage labels.

kind: role
version: v4
metadata:
  name: developer
spec:
  allow:
    windows_desktop_labels:
      environment: ["dev", "stage"]

    windows_desktop_logins: ["{{internal.windows_logins}}"]

Allow reviewers to see the hostnames of SSH Nodes

It is possible for a reviewer to view Resource Access Requests for SSH Nodes to which that reviewer does not have access. In this case, the reviewer will not be able to view the hostname of the requested node and they will only see the node's UUID.

To give the reviewer permission to view the Node hostname, use the allow.review_requests.preview_as_roles field in the reviewer's role, e.g.:

kind: role
spec:
  allow:
    review_requests:
      preview_as_roles: [access]

This can often be set to the same value as allow.review_requests.roles. When any of the preview_as_roles set for the reviewer would allow access to the requested node, the hostname will be displayed in the Review Request page of the Teleport Web UI.

Integrating with an external tool

With Teleport's Access Request plugins, users can manage Access Requests from within your organization's existing messaging and project management solutions.

IntegrationTypeSetup Instructions
SlackMessagingSet up Slack
MattermostMessagingSet up Mattermost
Microsoft TeamsMessagingSet up Microsoft Teams
JiraProject BoardSet up Jira
PagerDutyScheduleSet up PagerDuty
EmailMessagingSet up email
DiscordMessagingSet up Discord

Using TTLs with Access Requests

tsh request create supports flags to control TTLs for the request and elevated access. See the CLI Reference for more details.