Per-session MFA

Teleport supports requiring additional multi-factor authentication checks when starting new:

• SSH connections (a single tsh ssh call, Web UI SSH session or Teleport Connect SSH session)
• Kubernetes sessions (a single kubectl call)
• Database sessions (a single tsh db connect call)
• Desktop sessions

This is an advanced security feature that protects users against compromises of their on-disk Teleport certificates.

Prerequisites

tctl version
Teleport v14.2.1 git:api/14.0.0-gd1e081e go1.21
  
tsh version
Teleport v14.2.1 go1.21
Proxy version: 14.2.1Proxy: teleport.example.com

tctl version
Teleport Enterprise v14.1.3 git:api/14.0.0-gd1e081e go1.21
  
tsh version
Teleport v14.1.3 go1.21
Proxy version: 14.1.3Proxy: teleport.example.com

tctl version
Teleport Enterprise v14.2.1 git:api/14.0.0-gd1e081e go1.21
  
tsh version
Teleport v14.2.1 go1.21
Proxy version: 14.2.1Proxy: teleport.example.com

tctl version
Teleport Enterprise v14.1.3 git:api/14.0.0-gd1e081e go1.21
  
tsh version
Teleport v14.1.3 go1.21
Proxy version: 14.1.3Proxy: teleport.example.com

• To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials. tctl is supported on macOS and Linux machines. For example:

  tsh login --proxy=teleport.example.com --user=[email protected]
  tctl status
  Cluster  teleport.example.com
  Version  14.2.1
  CA pin   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

  If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.
• WebAuthn configured on this cluster
• Second factor hardware device, such as YubiKey or SoloKey
• A Web browser with WebAuthn support (if using SSH or desktop sessions from the Teleport Web UI).

teleport:
  auth_service:
    local_auth: false
    second_factor: optional
    webauthn:
      rp_id: teleport.example.com

Configure per-session MFA

Per-session MFA can be enforced cluster-wide or only for some specific roles.

Cluster-wide

auth_service:
  authentication:
    # require per-session MFA cluster-wide
    require_session_mfa: yes

tctl get cap > cap.yaml

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  require_session_mfa: true
version: v2

tctl create -f cap.yaml

tctl get cap > cap.yaml

kind: cluster_auth_preference
metadata:
  name: cluster-auth-preference
spec:
  require_session_mfa: true
version: v2

tctl create -f cap.yaml

Per role

To enforce MFA checks for a specific role, update the role to contain:

kind: role
version: v7
metadata:
  name: example-role-with-mfa
spec:
  options:
    # require per-session MFA for this role
    require_session_mfa: true
  allow:
    ...
  deny:
    ...

Role-specific enforcement only applies when accessing resources matching a role's allow section.

Roles example

Let's walk through an example of setting up per-session MFA checks for roles.

Jerry is an engineer with access to the company infrastructure. The infrastructure is split into development and production environments. Security engineer Olga wants to enforce MFA checks for accessing production servers. Development servers don't require this to reduce engineers' friction.

Olga defines two Teleport roles: access-dev and access-prod:

# access-dev.yaml
kind: role
version: v7
metadata:
  name: access-dev
spec:
  allow:
    node_labels:
      env: dev
    logins:
      - jerry
---
# access-prod.yaml
kind: role
version: v7
metadata:
  name: access-prod
spec:
  options:
    # require per-session MFA for production access
    require_session_mfa: true
  allow:
    node_labels:
      env: prod
    logins:
      - jerry
  deny: {}

Olga then assigns both roles to all engineers, including Jerry.

When Jerry logs into node dev1.example.com (with label env: dev as login jerry), nothing special happens:

tsh ssh [email protected]

[email protected] >

But when Jerry logs into node rod3.example.com (with label env: prod as login jerry), he gets prompted for an MFA check:

tsh ssh [email protected]
Tap any security key <tap>

[email protected] >

If per-session MFA was enabled cluster-wide, Jerry would be prompted for MFA even when logging into dev1.example.com.

tsh db connect prod-mysql-instance
Tap any security key

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 10002
Server version: 8.0.0-Teleport (Ubuntu)
Copyright (c) 2000, 2021, Oracle and/or its affiliates.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql>

Limitations

Current limitations for this feature are:

• For SSH connections besides the Web UI, the tsh or Teleport Connect client must be used for per-session MFA. (The OpenSSH ssh client does not work with per-session MFA).
• Only kubectl supports per-session WebAuthn authentication for Kubernetes.
• Database access with per-session MFA only works with tsh db connect. Per-session MFA for databases is not supported in Teleport Connect.
• Application access clients don't support per-session MFA authentication yet, although cluster and role configuration applies to them. If you enable per-session MFA checks cluster-wide, you will not be able to use Application access. We're working on integrating per-session MFA checks for these clients.
• For desktop access, only WebAuthn devices are supported.