Teleport Documentation

website·Indexed 39 days ago

https://goteleport.com/docs/

Zero trust access for infrastructure, including SSH servers, databases, Kubernetes clusters, and applications. Features the Agentic Identity Framework for securing AI agents, Model Context Protocol (MCP) integration, and client tools like tsh and Teleport Connect.

Tokens
757.5K
Snippets
3.7K
Records
5.2K
Agent score
70%

What's inside Teleport

  1. Overview of tbot CLI for Machine & Workload Identity

    tbot is a CLI tool used with Teleport Machine & Workload Identity to programmatically issue and renew short-lived certificates for service accounts, such as CI/CD servers.
    $ tbot [<flags>] <command> [<args> ...]
  2. Overview of Teleport Database Service for AlloyDB

    Teleport provides secure, fine-grained access control to AlloyDB via the Teleport Database Service. It uses GCP IAM authentication to communicate with AlloyDB; when a user connects, the Teleport Database Service obtains Google Cloud credentials and authenticates as an IAM principal with the necessary permissions to access the database.
  3. Overview of Okta SCIM integration for Teleport

    The SCIM (System for Cross-domain Identity Management) integration for Teleport Enterprise synchronizes Teleport user accounts with Okta user profiles. It automates onboarding and offboarding by creating, updating, and deleting Teleport accounts based on Okta organization changes.

    Key behaviors include:

    • Provisioning: When a user is assigned to the Okta app, a Teleport account is created. If a temporary SAML account already exists, it is promoted to a long-lived SCIM-managed account.
    • De-provisioning: When a user is unassigned or deactivated in Okta, Teleport immediately deletes the user and creates a session lock to terminate existing sessions and prevent credential reuse.
    • Suspension Caveat: Okta does not send SCIM updates when a user is 'suspended'. While the user cannot log back in, existing sessions are not terminated and pre-issued credentials remain valid until expiration.
  4. Overview of Teleport EC2 Auto-Discovery for AWS Organizations

    Teleport EC2 auto-discovery allows you to automatically enroll EC2 instances from an AWS organization into a Teleport cluster using the teleport-discovery-aws Terraform module. The Teleport Discovery Service queries the AWS API to identify matching accounts and EC2 instances. Once discovered, the service uses AWS Systems Manager (SSM) to install Teleport on the instance and join it to the cluster as a protected server.
  5. Overview of Microsoft Intune Integration for Device Trust

    The Microsoft Intune integration for Teleport Enterprise allows for the automatic synchronization of managed devices from Microsoft Intune into Teleport. This process acts as an inventory management step, effectively automating the tctl devices add commands. The integration periodically performs full and incremental (partial) syncs and removes devices from Teleport if they are removed from Intune. This integration is available exclusively as a hosted plugin via the Teleport Web UI; standalone service deployment is not supported.
  6. Overview of tbot deployment on Azure

    The tbot agent can be installed on Azure VMs using the azure delegated joining method. This method uses Azure's managed identity system—specifically an attested data document and JWT—to prove the VM's identity to the Teleport Auth Service. This removes the requirement for long-lived secrets during the joining process.
  7. Overview of Teleport Workload Identity with AWS Roles Anywhere

    Teleport Workload Identity issues short-lived X.509 certificates that AWS Roles Anywhere can use to authenticate machines to AWS services. This removes the need for long-lived credentials and allows machines to authenticate via Teleport's delegated join methods.

    Key characteristics:

    • Direct Access: Requests to AWS are not proxied through the Teleport Proxy Service, reducing latency but removing requests from Teleport's audit logs.
    • Compatibility: Works with any AWS client, including the AWS CLI and SDKs.
    • Human Use: While designed for machines, the tsh svid issue command can be used instead of tbot to allow human users to authenticate via AWS Roles Anywhere.
  8. Overview of Teleport Access Lists

    Access Lists are a feature of Teleport Enterprise Identity Governance that allow administrators and owners to grant and audit long-term access to resources. They function by controlling membership to specific roles and traits, which integrate directly into Teleport's Role-Based Access Control (RBAC) system.
  9. Overview of Teleport Machine and Workload Identity (MWI)

    Teleport Machine and Workload Identity (MWI) provides secure access for Non-Human Identities (NHIs) across various platforms and resource types. Common use cases include Infrastructure-as-Code (IaC) workflows and AI agent operations. A typical implementation involves executing commands on deployment targets (like Linux servers or Kubernetes clusters) through CI/CD pipelines using the tbot binary.
  10. Overview of Teleport Linux Desktop Access

    Teleport Linux Desktop Access (available in v18.11.0+) allows secure, audited access to Linux hosts running X11 desktop environments. The service runs on the target host, starts a virtual X11 display using Xvfb (X virtual framebuffer), and launches the user's chosen desktop environment. It establishes a reverse tunnel to the Teleport Proxy Service, requiring only a single outbound connection from the host (no inbound firewall rules needed). Available sessions are discovered from .desktop files in /usr/share/xsessions.
  11. Overview of Amazon Redshift Automatic User Provisioning

    Teleport can automatically create users in Amazon Redshift, eliminating the need to manually create individual accounts or use shared accounts.

    Key Constraints:

    • Automatic user provisioning is not compatible with Redshift Serverless.
    • Users created by Teleport are automatically assigned the teleport-auto-user role in the database.
    • If a user with the same name already exists in the database and is not managed by Teleport (not assigned the teleport-auto-user role), the connection will be aborted.