Skip to main content

Capabilities

The Teleport connector supports automatic account provisioning. Due to Teleport’s security rules, it is not possible to auto-generate and assign passwords to newly created accounts. When a new Teleport account is created by C1, a password reset link (associated with a token) will be sent to a vault. This allows the user to configure the password for their new account. This connector does not support account deprovisioning. You must deprovision accounts directly in Teleport.

Configure the Teleport connector

This connector only supports a self-hosted setup. Follow these instructions to use the Teleport connector, hosted and run in your own environment. See the connector’s README file for information on alternative setup methods. This guide walks you through setting up the Baton Teleport connector in Kubernetes to run continuously and sync with C1. The connector uses certificate-based authentication via tbot and connects to C1 using client credentials.

Prerequisites

Before you begin, make sure you have:
  • A Kubernetes cluster with kubectl access
  • A Teleport cluster with admin access
  • The tctl CLI tool configured for your Teleport cluster

Step 1: C1 setup

To complete this task, you’ll need:
  • The Connector Administrator or Super Administrator role in C1
1
In C1, navigate to Apps > Connectors and click Add connector.
2
Search for Baton and click Add.
3
Choose where to add the connector: Create a new app, or Add to an existing app (then select the app).If you’re creating a new app, choose whether to link it to an application discovered from your identity provider: select Yes and pick the IdP application, or No to continue with just the connector.
4
Set the connector’s Name and, optionally, a Description.
5
Click the pencil icon next to Owners to choose who can configure and manage this connector.
6
Click Add. The connector is created and its configuration page opens.
7
In the Settings area of the page, click Edit.
8
Click Rotate to generate a new Client ID and Secret. Carefully copy and save these credentials.

Step 2: Create Teleport bot and token

First, create the bot resource in Teleport:
Apply the bot configuration:
Next, create the join token. First, get your Kubernetes cluster’s JWKS:
Create the token configuration:
Apply the token:

Step 3: Create shared storage

Create persistent storage for sharing certificates between tbot and baton-teleport:
Apply the storage:

Step 4: Create RBAC for tbot

Create service account and RBAC permissions:
Apply RBAC:

Step 5: Deploy tbot

Create the tbot configuration:
Create the tbot deployment:
Apply tbot:

Step 6: Deploy Baton Teleport connector

Apply the baton-teleport deployment:

Step 7: Deploy and monitor the connector

Apply the baton-teleport deployment:
The connector will start automatically and run continuously, performing the following actions:
1
Install the baton-teleport binary (if not available via releases)
2
Connect to C1 using your client credentials
3
Poll for tasks from C1 periodically
4
Execute sync tasks when requested by C1
5
Handle provisioning requests when access needs to be granted/revoked
6
Send results back to C1 instead of writing to local files

Manual binary installation

If the automatic download fails, you can manually install the binary:

Verification steps

1

Check tbot is running:

2

Verify certificates are generated:

3

Check baton-teleport is running:

4

Verify connector connectivity:

The logs should show:
  • Successful connection to C1
  • Periodic polling for tasks
  • Any sync or provisioning activities

Troubleshooting

  • tbot CrashLoopBackOff: Check that the bot has roles assigned and JWKS is correct
  • Certificate access issues: Verify PVC is mounted and tbot is writing to /opt/machine-id
  • Connection issues: Ensure proxy address is correct and network policies allow outbound connections

Customization

  • Adjust bot roles based on what Teleport resources you need to access
  • Modify resource limits based on your cluster capacity
  • Update Teleport cluster and proxy addresses throughout the configuration
  • Consider using secrets for sensitive configuration instead of environment variables