{"token_count": 3750}

# Creating an Access List for Just-in-Time Access

Identity Governance is available only with Teleport Enterprise.

The **Just-in-Time Access Guide** creates an Access List whose members are required to request access to a defined set of resources, rather than being granted that access automatically. The list's members submit an [Access Request](https://goteleport.com/docs/ver/19.x/identity-governance/access-requests.md); the list's owners review and approve or deny it. Once approved, the member receives temporary access bounded by the request's TTL, capped by the member's remaining Teleport session.

This guide will help you:

- Decide when a Just-in-Time Access List is the right fit
- Create one using the guided flow
- Verify the request-and-approval experience as a member

## When to use this flow

Use a Just-in-Time Access List when:

- The resources are sensitive enough that members should justify each access event.
- You want a clear audit trail of *who requested what, when, and who approved it*.
- You want a single list to govern who can request the access, with periodic reviews so the membership is reaffirmed rather than left to drift.
- You'd rather configure access through a guided UI than write role specs by hand.

If members instead need access immediately on login for the duration of their session, use the [Standing Access Guide](https://goteleport.com/docs/ver/19.x/identity-governance/access-lists/standing-access-list.md) instead.

## Prerequisites

- A running Teleport Enterprise (v18.8.0 or higher) cluster. If you want to get started with Teleport, [sign up](https://goteleport.com/signup) for a free trial or [set up a demo environment](https://goteleport.com/docs/ver/19.x/get-started/deploy-community.md).

- The `tctl` and `tsh` clients, required only if deploying with Terraform.

  Installing `tctl` and `tsh` clients

  1. Determine the version of your Teleport cluster. The `tctl` and `tsh` clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at `/v1/webapi/find` and use a JSON query tool to obtain your cluster version. Replace teleport.example.com:443 with the web address of your Teleport Proxy Service:

     **Mac/Linux**

     ```
     $ TELEPORT_DOMAIN=teleport.example.com:443
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     ```

     **Windows - Powershell**

     ```
     $ $TELEPORT_DOMAIN = "teleport.example.com:443"
     $ $TELEPORT_VERSION = (Invoke-RestMethod -Uri "https://${TELEPORT_DOMAIN}/v1/webapi/find").server_version
     ```

  2. Follow the instructions for your platform to install `tctl` and `tsh` clients:

     **Mac**

     Download the signed macOS .pkg installer for Teleport, which includes the `tctl` and `tsh` clients:

     ```
     $ curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkg
     ```

     In Finder double-click the `pkg` file to begin installation.

     ---

     DANGER

     Using Homebrew to install Teleport is not supported. The Teleport package in Homebrew is not maintained by Teleport and we can't guarantee its reliability or security.

     ---

     **Windows - Powershell**

     ```
     $ curl.exe -O https://cdn.teleport.dev/teleport-v$TELEPORT_VERSION-windows-amd64-bin.zip
     Unzip the archive and move the `tctl` and `tsh` clients to your %PATH%
     NOTE: Do not place the `tctl` and `tsh` clients in the System32 directory, as this can cause issues when using WinSCP.
     Use %SystemRoot% (C:\Windows) or %USERPROFILE% (C:\Users\<username>) instead.
     ```

     **Linux**

     All of the Teleport binaries in Linux installations include the `tctl` and `tsh` clients. For more options (including RPM/DEB packages and downloads for i386/ARM/ARM64) see our [installation page](https://goteleport.com/docs/ver/19.x/installation/single-machine.md).

     ```
     $ curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ tar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gz
     $ cd teleport
     $ sudo ./install
     Teleport binaries have been copied to /usr/local/bin
     ```

* At least one user who will be a member of the list, preferably a user with no access to resources to verify the access flow later.

* At least one resource enrolled in the cluster for the Access List to grant access to.

- Permissions to create Access Lists, users, and roles. These are included in the preset [`editor`](https://goteleport.com/docs/ver/19.x/reference/access-controls/roles.md#preset-roles) role, or you can copy and paste the following into your own role:
  ```
  allow:
    rules:
    - resources:
      - access_list
      - user
      - role
      verbs:
      - read
      - list
      - create
      - update
      - delete

  ```

## Step 1/3. Start the guide

In the Teleport Web UI, hover over **Add New** from the sidebar menu then click **Access List**.

Enter a name and optional description for the list.

Click **Just-in-Time Access Guide** and click **Start Guide**.

## Step 2/3. Walk through the guide

The guide steps you through:

1. **Define Access to Resources** — for each resource type, specify the matching criteria. Most resource types are matched by [labels](https://goteleport.com/docs/ver/19.x/zero-trust-access/rbac-get-started/labels.md); others may ask you to select the resource itself. Members can request access to anything that matches.

   ---

   PREVIEWING RESOURCES

   After defining access for a resource type, the UI shows a preview of matching resources. The preview is limited by your own role permissions — members may be granted access to additional resources that aren't visible to you.

   ---

2. **Define Resource Identities or Principals** — for resource types that need them (e.g. SSH logins, database users, Kubernetes users/groups, etc.), specify which principals members can use to connect once their request is approved.

3. **Basic Information** — confirm the name and description of the Access List, and select the next review date. Periodic reviews are how list owners reaffirm that the right members are still on the list.

   Note: Access Lists deployed through Terraform are "static" lists and do not support periodic auditing — the review date is ignored.

4. **Define Membership** — add the users who should be eligible to request access through this list.

5. **Define Ownership** — add the users responsible for managing the list, reviewing membership, and reviewing Access Requests submitted through this list.

### Deploy the Access List

At the final **Deployment** step, choose how to apply the list:

**Manage in Teleport**

Click **Create Access List Now**. The list is created directly via the Teleport API and is immediately active.

**Manage via Terraform**

Click **Continue via Terraform**. Follow the in-UI instructions or below to deploy with Terraform:

1. **Add the Terraform module to your configuration.**

   Click the **Copy Terraform Module** button, then paste it into a Terraform configuration file.

2. **Log in to your cluster**, assigning email\@example.com to your Teleport username:

   ```
   $ tsh login --proxy=teleport.example.com:443 --user=email@example.com
   ```

3. **Generate a temporary bot:**

   ```
   $ eval "$(tctl terraform env)"
   ```

4. **Initialize Terraform:**

   ```
   $ terraform init
   ```

5. **Preview the changes:**

   ```
   $ terraform plan
   ```

6. **Apply the changes:**

   ```
   $ terraform apply
   ```

The Access List is created once `terraform apply` completes.

---

NOTE

The steps above use `tctl terraform env` to issue short-lived credentials, which is convenient for trying things out locally. For remote environments such as CI/CD pipelines or cloud VMs, see the [Terraform provider documentation](https://goteleport.com/docs/ver/19.x/configuration/terraform-provider.md) for guidance on setting up the provider.

---

### Example Terraform configuration

Below is an example of the Terraform module the UI generates for a JIT Access List. The example grants list members the ability to request access to SSH servers matching the `env: test` label and log in as `ubuntu` (see the standard role definition below).

Customize the placeholders below to fit your setup — each one is reused throughout the config wherever it appears:

- teleport.example.com:443 — your Teleport proxy address.
- acl-id — a unique identifier for the Access List (alphanumerics only). It ties the roles, list, and member resources together.
- acl-title — the display title for the Access List.
- example-owner — the Teleport user to add as an owner.
- example-member — the Teleport user to add as a member.

```
terraform {
  required_providers {
    teleport = {
      source  = "terraform.releases.teleport.dev/gravitational/teleport"
      version = "~> 19.0"
    }
  }
}

provider "teleport" {
  addr = "teleport.example.com:443"
}

# A role that defines access to standard resources.
resource "teleport_role" "access-standard-acl-preset-acl-id" {
  version = "v8"

  metadata = {
    name = "access-standard-acl-preset-acl-id"
    labels = {
      "teleport.dev/iac-tool"                = "terraform"
      "teleport.internal/access-list-preset" = "acl-id"
    }
  }

  spec = {
    allow = {
      logins = ["ubuntu"]
      node_labels = {
        env = ["test"]
      }
    }
  }
}

# A role that allows requesting access to resources (assigned to members).
resource "teleport_role" "requester-acl-preset-acl-id" {
  version = "v8"

  metadata = {
    name = "requester-acl-preset-acl-id"
    labels = {
      "teleport.dev/iac-tool"                = "terraform"
      "teleport.internal/access-list-preset" = "acl-id"
    }
  }

  spec = {
    allow = {
      request = {
        search_as_roles = ["access-standard-acl-preset-acl-id"]
      }
    }
  }
}

# A role that allows reviewing access requests (assigned to owners).
resource "teleport_role" "reviewer-acl-preset-acl-id" {
  version = "v8"

  metadata = {
    name = "reviewer-acl-preset-acl-id"
    labels = {
      "teleport.dev/iac-tool"                = "terraform"
      "teleport.internal/access-list-preset" = "acl-id"
    }
  }

  spec = {
    allow = {
      review_requests = {
        roles            = ["access-standard-acl-preset-acl-id"]
        preview_as_roles = ["access-standard-acl-preset-acl-id"]
      }
    }
  }
}

resource "teleport_access_list" "acl-acl-id" {
  header = {
    kind    = "access_list"
    version = "v1"
    metadata = {
      name = "acl-id"
      labels = {
        "teleport.dev/iac-tool"                      = "terraform"
        "teleport.internal/access-list-preset"       = "short-term"
        "teleport.internal/access-list-preset-roles" = "reviewer-acl-preset-acl-id,requester-acl-preset-acl-id,access-standard-acl-preset-acl-id"
      }
    }
  }

  spec = {
    type = "static"
    title = "acl-title"
    grants = {
      roles = ["requester-acl-preset-acl-id"]
    }
    owner_grants = {
      roles = ["reviewer-acl-preset-acl-id"]
    }
    owners = [{
      membership_kind = "1"
      name            = "example-owner"
    }]
  }
}

resource "teleport_access_list_member" "acl-member-example-member" {
  depends_on = [teleport_access_list.acl-acl-id]

  header = {
    kind    = "access_list_member"
    version = "v1"
    metadata = {
      name = "example-member"
    }
  }

  spec = {
    access_list     = "acl-id"
    name            = "example-member"
    membership_kind = "1"
  }
}

```

---

EDITING THE GENERATED ROLES

Avoid directly modifying the roles the guided flow creates for this Access List. Keep their names and their `teleport.internal/access-list-preset*` labels unchanged — the Web UI relies on both to recognize them as the roles generated for this Access List. To change what the list grants, update it through the Web UI Access List editor:

1. From the sidebar menu, click **Identity Governance** > **Access Lists**.
2. Click on the target Access List.
3. Click the **Access Definition** tab.
4. Click **Edit Access**.

If you created the list with Terraform produced by the Web UI editor, you can still use the web editor to update the Access List and copy the updated Terraform it generates.

Editing the roles directly (via Terraform, `tctl`, or the role editor) may make the Access List editor in the Web UI unable to parse them (only a limited subset of role fields is supported by the editor) — at which point you can no longer use the Web UI editor to change the list's grants, and must update the roles directly for the rest of the Access List's life.

---

## Step 3/3. Verify the request flow

Log in as one of the **members** you added. The resources you defined in **Define Access to Resources** should appear in the resource list with a **Request Access** button rather than a direct connect button.

1. Submit a request for one of the resources, optionally providing a reason.
2. Log in as one of the **owners** and approve the request. (The JIT preset grants owners a `reviewer` role automatically, which is what lets them approve.)
3. Back as the member, assume the approved request. You now have temporary access to the resource; once the request expires or your session ends, the access is gone.

## Next steps

- Create an Access List whose members get access on login with the [Standing Access Guide](https://goteleport.com/docs/ver/19.x/identity-governance/access-lists/standing-access-list.md).
- Create an Access List by assigning existing roles directly with the [Custom Form](https://goteleport.com/docs/ver/19.x/identity-governance/access-lists/custom-access-list.md).
- Learn more about how members request and reviewers approve access in [Access Requests](https://goteleport.com/docs/ver/19.x/identity-governance/access-requests.md).
- Auto-approve low-risk requests with [automatic reviews](https://goteleport.com/docs/ver/19.x/identity-governance/access-requests/automatic-reviews.md).
- Route request notifications with [notification routing rules](https://goteleport.com/docs/ver/19.x/identity-governance/access-requests/notification-routing-rules.md).
- Group members by inheriting access from other lists with [nested Access Lists](https://goteleport.com/docs/ver/19.x/identity-governance/access-lists/nested-access-lists.md).
- Learn more about managing Access Lists as code with the [Terraform provider and Kubernetes operator](https://goteleport.com/docs/ver/19.x/configuration/resource-guides/access-list.md).