Joining Services via Azure Managed Identity
- Available for:
This guide will explain how to use the Azure join method to configure Teleport instances to join your Teleport cluster without sharing any secrets when they are running in an Azure Virtual Machine.
The Azure join method is available in Teleport 12.1+. It is available to any Teleport process running in an Azure Virtual Machine. Support for joining a cluster with the Proxy Service behind a layer 7 load balancer or reverse proxy is available in Teleport 13.0+.
For other methods of joining a Teleport process to a cluster, see Joining Teleport Services to a Cluster.
- An Azure Virtual Machine running Linux with the Teleport binary installed. The Virtual Machine must have a Managed Identity assigned to it with permission to read virtual machine info.
- To check that you can connect to your Teleport cluster, sign in with
tsh login, then verify that you can run
tctlcommands using your current credentials.
tctlis supported on macOS and Linux machines. For example:If you can connect to the cluster and run thetsh login --proxy=teleport.example.com --user=[email protected]tctl status
CA pin sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl statuscommand, you can use your current credentials to run subsequent
tctlcommands from your workstation. If you host your own Teleport cluster, you can also run
tctlcommands on the computer that hosts the Teleport Auth Service for full permissions.
Every virtual machine hosting a Teleport process using the Azure method to join
your Teleport cluster needs a Managed Identity assigned to it. The identity
Microsoft.Compute/virtualMachines/read permission so Teleport can
look up the virtual machine. No other permissions are required.
Under the hood, Teleport processes will prove that they are running in your Azure subscription by sending a signed attested data document and access token to the Teleport Auth Service. The VM's identity must match an allow rule configured in your Azure joining token.
Create the following
token.yaml with an
allow rule specifying your Azure
subscription and the resource group that your VM's identity must match.
# the token name is not a secret because instances must prove that they are
# running in your Azure subscription to use this token
# use the minimal set of roles required
# specify the Azure subscription which Teleport processes may join from
- subscription: 11111111-1111-1111-1111-111111111111
# multiple allow rules are supported
- subscription: 22222222-2222-2222-2222-222222222222
# resource_groups is optional and allows you to restrict the resource group of
# joining Teleport processes
- subscription: 33333333-3333-3333-3333-333333333333
resource_groups: ["group1", "group2"]
The token name
azure-token is just an example and can be any value you want to
use, as long as you use the same value for
join_params.token_name in Step 3.
Run the following command to create the token:
tctl create -f token.yaml
The Azure join method can be used for Teleport processes running the SSH, Proxy, Kubernetes, Application, Database, or Desktop Service.
Configure your Teleport process with a custom
teleport.yaml file. Use the
join_params section with
token_name matching your token created in Step 2
method: azure as shown in the following example config:
# client_id is the client ID of the managed identity created in Step 1.
Start Teleport on the Azure VM.
Configure your Teleport instance to start automatically when the host boots up by creating a systemd service for it. The instructions depend on how you installed your Teleport instance.
You can check the status of your Teleport instance with
systemctl status teleport
and view its logs with
journalctl -fu teleport.
Confirm that your Teleport process is able to connect to and join your cluster. You're all set!