Teleport Workload Identity with SPIFFE: Achieving Zero Trust in Modern Infrastructure
May 23
Virtual
Register Today
Support
LOG IN
Teleport logoTry For Free
Contact SalesTry for Free
Support
LOG IN
Fork me on GitHub

Teleport

MFA for Administrative Actions

Version 15.x

Teleport can be configured to require additional multi-factor authentication checks to perform administrative actions through tctl, tsh, the Web UI, Teleport Connect, and any other Teleport client.

Examples of administrative actions include, but are not limited to:

  • Resetting or recovering user accounts
  • Inviting new users
  • Updating cluster configuration resources
  • Modifying access management resources
  • Approving access requests
  • Generating new join tokens
  • Impersonation
  • Creating new bots for Machine ID

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

When MFA for administrative actions is enabled, user certificates produced with tctl auth sign will no longer be suitable for automation due to the additional MFA checks.

We recommend using Machine ID to issue certificates for automated workflows, which uses role impersonation that is not subject to MFA checks.

Certificates produced with tctl auth sign directly on an Auth Service instance using the super-admin role are not subject to MFA checks to support legacy self-hosted setups.

Prerequisites

  • A running Teleport cluster version 15.2.4 or above. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

  • The tctl admin tool and tsh client tool.

    On Teleport Enterprise, you must use the Enterprise version of tctl, which you can download from your Teleport account workspace. Otherwise, visit Installation for instructions on downloading tctl and tsh for Teleport Community Edition.

  • 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  15.2.4
    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).

Require MFA for administrative actions

MFA for administrative actions is automatically enforced for clusters where WebAuthn is the only form of second factor allowed.

In a future major version, Teleport may enforce MFA for administrative actions for a wider range of cluster configurations.

Edit the cluster_auth_preference resource:

tctl edit cap

Update the cluster_auth_preference definition to include the following content:

kind: cluster_auth_preference
version: v2
metadata:
  name: cluster-auth-preference
spec:
  type: local
  # To make webauthn the only form of second factor allowed, set this field to 'webauthn'.
  second_factor: "webauthn"
  webauthn:
    rp_id: example.com

Save and exit the file. tctl will update the remote definition:

cluster auth preference has been updated

Edit the Auth Service's teleport.yaml file and restart all Auth Service instances:

# snippet from /etc/teleport.yaml:
auth_service:
  authentication:
    type: local
    # To make webauthn the only form of second factor allowed, set this field to 'webauthn'.
    second_factor: "webauthn"
    webauthn:
      rp_id: example.com