Creating an Access List for Standing Access
The Standing Access Guide creates an Access List whose members are automatically granted access to a defined set of resources when they log in. No Access Request is required.
This guide will help you:
- Decide when a Standing Access List is the right fit
- Create one using the guided flow in the Teleport Web UI
- Verify that members get access on login
When to use this flow
Use a Standing Access List when:
- Members need the access as part of their day-to-day work.
- The set of resources is well-scoped (e.g. internal dashboards for the analytics team) and changes infrequently.
- You want a single list to govern who has 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 should instead request temporary access, use the Just-in-Time Access Guide instead.
Prerequisites
-
A running Teleport Enterprise (v18.8.0 or higher) cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.
-
The
tctlandtshclients, required only if deploying with Terraform.Installing
tctlandtshclients-
Determine the version of your Teleport cluster. The
tctlandtshclients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at/v1/webapi/findand 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
- Windows - Powershell
TELEPORT_DOMAIN=teleport.example.com:443TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"$TELEPORT_DOMAIN = "teleport.example.com:443"$TELEPORT_VERSION = (Invoke-RestMethod -Uri "https://${TELEPORT_DOMAIN}/v1/webapi/find").server_version -
Follow the instructions for your platform to install
tctlandtshclients:- Mac
- Windows - Powershell
- Linux
Download the signed macOS .pkg installer for Teleport, which includes the
tctlandtshclients:curl -O https://cdn.teleport.dev/teleport-${TELEPORT_VERSION?}.pkgIn Finder double-click the
pkgfile to begin installation.dangerUsing 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.
curl.exe -O https://cdn.teleport.dev/teleport-v$TELEPORT_VERSION-windows-amd64-bin.zipUnzip 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.
All of the Teleport binaries in Linux installations include the
tctlandtshclients. For more options (including RPM/DEB packages and downloads for i386/ARM/ARM64) see our installation page.curl -O https://cdn.teleport.dev/teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gztar -xzf teleport-v${TELEPORT_VERSION?}-linux-amd64-bin.tar.gzcd teleportsudo ./installTeleport 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
editorrole, 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 Standing Access Guide and click Start Guide.
Step 2/3. Walk through the guide
The guide steps you through:
-
Define Access to Resources — for each resource type, specify the matching criteria. Most resource types are matched by labels; others may ask you to select the resource itself. Members get access to anything that matches when they log in.
Previewing ResourcesAfter 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.
-
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.
-
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.
-
Define Membership — add the users who should receive the access.
-
Define Ownership — add the users responsible for managing the list and reviewing membership.
Deploy the Access List
At the final Deployment step, choose how to apply the list:
- Manage in Teleport
- Manage via Terraform
Click Create Access List Now. The list is created directly via the Teleport API and is immediately active.
Click Continue via Terraform. Follow the in-UI instructions or below to deploy with Terraform:
-
Add the Terraform module to your configuration.
Click the Copy Terraform Module button, then paste it into a Terraform configuration file.
-
Log in to your cluster, assigning [email protected] to your Teleport username:
tsh login --proxy=teleport.example.com:443 --user=[email protected] -
Generate a temporary bot:
eval "$(tctl terraform env)" -
Initialize Terraform:
terraform init -
Preview the changes:
terraform plan -
Apply the changes:
terraform apply
The Access List is created once terraform apply completes.
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
for guidance on setting up the provider.
Example Terraform configuration
Below is an example of the Terraform module the UI generates for a Standing
Access List. The example grants list members standing access to SSH servers
matching the env: test label, with ubuntu as the allowed login (see the
standard role 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.
- unique-access-list-id — a unique identifier for the Access List (alphanumerics only). It ties the roles, list, and member resources together.
- Example Access List — 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 config for creating an Access List that grants members direct
# access to Teleport resources defined in the associated roles.
terraform {
required_providers {
teleport = {
source = "terraform.releases.teleport.dev/gravitational/teleport"
version = "~> 18.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. Can optionally be assigned to any users outside of this access list.
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" = "long-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 = ["access-standard-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"
}
}
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:
- From the sidebar menu, click Identity Governance > Access Lists.
- Click on the target Access List.
- Click the Access Definition tab.
- 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 access
Log in as one of the members you added. The resources you defined in Define Access to Resources should appear in the resource list and you should be able to connect to them immediately.
Next steps
- Create an Access List whose members request temporary access with the Just-in-Time Access Guide.
- Create an Access List by assigning existing roles directly with the Custom Form.
- Group members by inheriting access from other lists with nested Access Lists.
- Learn more about managing Access Lists as code with the Terraform provider and Kubernetes operator.