Types of users
Unlike traditional SSH, Teleport introduces the concept of a User Account. A User Account is not the same as SSH login. Instead, each Teleport User is associated with another account which is used to authenticate the user.
For Open Source edition users, these will be OS users who are administered
outside of Teleport on each cluster node. For example, there can be a Teleport user joe who can be permitted to log in as "root" to a specific subset of nodes. Another user juliet could be permitted to OS users root and to nginx. Teleport does not know the OS Users so it expects both root and nginx to exist on the node.
For Enterprise edition users, these can be stored in an external identity source such as OKTA, Active Directory, OneLogin, G Suite, or OIDC. Read the Enterprise Guide to learn more.
Teleport supports two types of user accounts: Local Users and External Users.
Local users
Local users are created and stored in Teleport's own identity storage in the Auth Server.
Let's look at this table:
| Teleport User | Allowed OS Logins | Description |
|---|---|---|
| joe | joe, root | Teleport user joe can log in into member nodes as OS user joe or root. |
| juliet | juliet | Teleport user juliet can log in into member nodes only as OS user juliet. |
| ross | If no OS login is specified, it defaults to the same name as the Teleport user, here this is ross. |
To add a new user to Teleport, you have to use the tctl tool on the same node
where the auth server is running, i.e. teleport was started with
--roles=auth .
A cluster administrator must create account entries for every Teleport user with
tctl users add. Every Teleport User must be associated with a list of one or more machine-level OS usernames it can authenticate as during a login. This list is called "user mappings".
The diagram shows the following mappings. A couple of noteworthy things from this example:
- Teleport User
sandradoes not have access tograv-02through Teleport becauseopsis not an OS username on that node. - Teleport User
joehas access to all nodes because the OS userrootis present on all nodes.
| Teleport User | logins | has access to nodes |
|---|---|---|
| joe | root, joe | grav-00, grav-01, grav-02 |
| tara | tara | grav-01, grav-02 |
| teleport | teleport | grav-00, grav-02 |
| sandra | ops | grav-00, grav-01 |
Teleport supports second-factor authentication (2FA) when using a local auth connector and it is enforced by default.
There are two types of 2FA supported:
TOTP is the default. You can use Google
Authenticator or
Authy or any other TOTP client.
External users
External users are users stored elsewhere within an organization. Examples include Github, Active Directory (AD), OIDC, or any identity store with an OpenID/OAuth2 or SAML endpoint.
Multiple identity sources
It is possible to have multiple identity sources configured for a Teleport cluster. In this case, an identity source (called a "connector") will have to be passed to tsh --auth=connector_name login.
The local users connector can be specified via tsh --auth=local
login.
User roles
Unlike traditional SSH, each Teleport user account is assigned a role. Having roles allows Teleport to implement role-based access control (RBAC), i.e. assign users to groups (roles) and restrict each role to a subset of actions on a subset of nodes in a cluster.