Teleport Machine Identity (also called Machine & Workload Identity, or MWI) eliminates long-lived static credentials from your infrastructure. Instead of distributing API keys, service account tokens, or shared passwords to machines, Teleport issues short-lived cryptographic certificates that automatically renew — and expire if compromised. This gives your automation the same strong identity guarantees that human users get through SSO and MFA. At the core of Machine Identity isDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/gravitational/teleport/llms.txt
Use this file to discover all available pages before exploring further.
tbot, a lightweight agent that runs on your machine or inside your CI/CD pipeline. tbot authenticates to the Teleport cluster using a platform-specific join method — for example, a GitHub Actions OIDC token, an AWS IAM role, or a Kubernetes service account — and then writes short-lived certificates to a local destination for other tools to consume.
The problem with static credentials
Traditional automation relies on long-lived secrets: API tokens, SSH keys, and service account credentials that are created once and then shared or embedded in configuration files. These secrets:- Accumulate over time and become difficult to audit or rotate
- Are hard to scope — a single leaked token may grant broad access
- Bypass identity controls because they are not tied to a specific workload
- Persist long after the workflow that needed them has finished
Core concepts
Bots
A bot is a non-human identity in Teleport. Bots have roles assigned to them, their activity is recorded in audit logs, and their identity is encoded in short-lived x.509 certificates signed by the Teleport Auth Service — the same way human user certificates are issued. You create and manage bots usingtctl.
Join tokens
Bots do not authenticate with a username and password. Instead, they use a join token that encodes which bot they represent and what cryptographic proof (join method) they must present. Supported join methods include GitHub Actions, GitLab CI, CircleCI, AWS IAM, GCP, Azure, Kubernetes, and others. When the platform-provided proof is valid, Teleport issues the bot its identity without any shared secret ever being stored.Bot Instances
Each time a newtbot process joins the cluster from scratch, it creates a Bot Instance — a server-side record that tracks a specific installation over time through certificate renewals. You can inspect Bot Instances with tctl get bot_instance to see which installations are active and when they last authenticated.
Artifacts
The files written bytbot — signed certificates, kubeconfig files, SSH config files — are called artifacts. Artifacts are placed in a configured destination (a directory, a Kubernetes Secret, or in-memory) and are automatically rotated before they expire.
Use cases
- CI/CD pipelines — GitHub Actions, GitLab CI, CircleCI, Jenkins, and other CI systems can use their native OIDC tokens to authenticate as a bot without storing any Teleport credentials in the repository.
- Kubernetes workloads — Pods running in enrolled clusters can join using the Kubernetes join method and receive credentials for accessing other Teleport-protected resources.
- Service-to-service authentication — Workloads can receive SPIFFE-compatible X.509 or JWT identities (SVIDs) for mutual TLS or JWT-based authentication between services.
- Cloud provider access — Bots can authenticate to AWS, GCP, and Azure APIs using short-lived JWT SVIDs via Workload Identity Federation, with no cloud credentials stored in Teleport.
- Infrastructure as Code — Terraform, Ansible, and other IaC tools can use Machine Identity to access Teleport’s API and managed resources without static admin credentials.
Machine Identity vs Workload Identity
Teleport MWI provides two complementary capabilities:| Zero Trust Access for Machines | Workload Identity (SPIFFE) | |
|---|---|---|
| Purpose | Access Teleport-protected infrastructure | Authenticate workloads to each other or to cloud APIs |
| Standards | Teleport-native x.509 credentials | SPIFFE SVIDs (x.509 or JWT) |
| Proxy usage | Traffic goes through the Teleport Proxy | No Teleport Proxy involved |
| Delivery | Files written to disk via tbot | Filesystem, Kubernetes Secret, or SPIFFE Workload API |
tbot agent and the same Teleport RBAC system.
Workload Identity (SPIFFE/SVID support) is covered in detail on the Workload Identity page.
Get started
Getting Started
Issue your first bot certificate in minutes using a GitHub Actions workflow and a Linux server or Kubernetes cluster.
Workload Identity
Learn how Teleport issues SPIFFE-compatible SVIDs to workloads for service-to-service authentication and cloud API access.
tbot Reference
Explore the full tbot configuration format, command reference, output destinations, and renewal behavior.
Deployment Architecture
Understand how the Auth Service, Proxy, and tbot agent interact within the broader Teleport architecture.