Skip to content

Latest commit

 

History

History
583 lines (452 loc) · 17.9 KB

resource-requests.mdx

File metadata and controls

583 lines (452 loc) · 17.9 KB
Raw
title description h1
Resource Access Requests
Teleport allows users to request access to specific resources from the CLI or UI. Requests can be escalated via ChatOps or anywhere else via our flexible Authorization Workflow API.
Teleport Resource Access Requests
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.

<ScopedBlock scope={["oss"]}>

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

(!docs/pages/includes/commercial-prereqs-tabs.mdx!)

(!docs/pages/includes/tctl.mdx!)

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](#integrating-with-an-external-tool) 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

$ tsh ssh alice@iot
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.

$ tsh ssh alice@iot
ERROR: access denied to alice connecting to iot on cluster teleport.example.com

You do not currently have access to alice@iot, 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 <Var name="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=<Var name="kube-cluster" /> \
[--kube-namespace=<Var name="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

(!docs/pages/includes/access-request-integrations.mdx!)

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.