Restrict Access for Privileged Accounts

As an administrator, you need to make informed decisions about when and how to grant privileged access to the resources in your infrastructure, including the Teleport services that protect those resources. You also need to manage access to the cluster storage backend and determine whether to apply network-level restrictions.

Labels and label expressions

As you learned in Add Labels to Resources, labels enable you to group, filter, and control access to nodes and services in your infrastructure that you want to protect with Teleport. When combined with allow and deny rules in Teleport roles, labels become the primary mechanism for granting or denying access to critical resources. Users who can add or modify labels can—either intentionally or unintentionally—make changes that result in privilege elevation when other users' roles are evaluated.

To prevent changes to labels from granting elevated privileges, you should:

• Carefully consider how allow and deny rules are defined and interact in every role.
• Restrict access to the Teleport process and Teleport configuration files on all nodes in the cluster.
• Use care in defining dynamic labels that execute commands.
• Review sources used to generate dynamic labels and restrict modifications to the command or the data sources used.
• Follow the principle of least privilege in creating and assigning roles. Don't give users permissive roles when more a restrictive role will do. For example, don't assign users the preset access or editor role, which give them permission to access and edit all cluster resources. Instead, define roles with the minimum required permissions for each user and configure access requests or access lists to provide temporary elevated permissions.

Restrict root access

You should be highly selective in allowing any user to have root privileges or access to other accounts with administrative privileges. Privileged users could manipulate Teleport agents in ways that affect your authorization controls. For example, a privileged user with access to the Teleport configuration file might modify settings to bypass role-based access controls. Similarly, a user with elevated access to the Teleport Auth Service, Teleport Proxy Service, or Teleport agent services might replace the Teleport executable to infiltrate or exfiltrate cluster systems, manipulate the discovery of dynamic resources, compromise sensitive credentials and sessions, or obscure auditing.

To prevent elevated privileges from resulting in security incidents, you should adhere to the following guidelines:

• Create new, non-root, users and use test instances for experimenting with Teleport.
• Run all Teleport agent services except the SSH Service as a non-root user. The SSH Service requires root access, so you should limit access to the SSH Service. The Teleport Proxy Service must also have root permission—or the CAP_NET_BIND_SERVICE capability—to allow Teleport listen on any port number less than 1024, including port 443.
• Avoid allowing sudo in production environments unless it's necessary.
• Secure all Teleport executables so that they can't be modified or replaced.
• Secure Teleport configuration files so that they can't be modified or replaced.
• Ensure the users' client ~/.tsh directory is secure and should not be copied. If a user's tsh client is compromised, it could result in a compromise of that user.

Prevent access to storage

You should make sure that the Teleport storage backend you use can't be accessed directly or modified. For example, you should ensure that the storage you use for audit log events and session recordings is secured so the data can't be tampered with. For more information about managing storage, see Storage backends

Restrict network access

Teleport doesn't provide network restrictions. For example, you need to consider if port forwarding should be allowed, and if it is, which roles allow it and what resources can be accessed. You want to prevent a condition where a user establishes network access through Teleport, then uses another client and protocol outside of the Teleport cluster auditing system to access additional systems.