Skip to main content

Teleport

Visualize Teleport users, roles, and access lists, map role assignments and access list membership across your infrastructure, and monitor changes through queries and alerts.

Installation​

info

This integration authenticates to the Teleport auth service over gRPC with mutual TLS. No passwords, API keys, or OAuth tokens are used — all traffic is authenticated with a client certificate issued by the cluster's own CA and delivered to JupiterOne as a single identity file (a PEM bundle containing the private key, TLS client certificate, and cluster CA certificates).

Prerequisites​

  • A Teleport cluster (Cloud or self-hosted) reachable on port 443.
  • The tctl and tsh CLI tools, running as a cluster administrator that has permission to create roles, create local users, and impersonate the service user you are about to create.

Configuration in Teleport​

1. Log in to the cluster as an administrator​

tsh login --proxy=<cluster>.teleport.sh:443 --user=<admin-user>

2. Create the read-only role for JupiterOne​

Save the following to jupiterone-role.yaml:

kind: role
version: v7
metadata:
  name: jupiterone-reader
spec:
  allow:
    rules:
      - resources:
          [user, role, access_list, access_list_member, access_list_review]
        verbs: [list, read]

Then apply it:

tctl create -f jupiterone-role.yaml

3. Grant your admin user permission to sign an identity for the service user​

tctl auth sign --user=<other-user> requires explicit impersonation rights, which the preset editor role does not include. Create this role and attach it to your admin user:

kind: role
version: v7
metadata:
  name: jupiterone-impersonator
spec:
  allow:
    impersonate:
      users: ['jupiterone']
      roles: ['jupiterone-reader']
tctl create -f jupiterone-impersonator.yaml
tctl users update <admin-user> --set-roles=<existing-roles>,jupiterone-impersonator
tsh logout && tsh login --proxy=<cluster>.teleport.sh:443 --user=<admin-user>

Re-logging in is required so the admin's session certificate picks up the new role.

4. Create the local service user and finish its invite​

tctl users add jupiterone --roles=jupiterone-reader

This prints a one-hour invite URL. Open it in a browser and complete password + MFA setup for the jupiterone user. Local authentication with MFA is required — SSO users cannot be used to sign identity files because tctl auth sign needs a password-backed user.

5. Sign the identity file​

tctl auth sign \
  --user=jupiterone \
  --format=file \
  --out=jupiterone-identity.pem \
  --ttl=24h

The PEM bundle written to jupiterone-identity.pem is what you will upload to JupiterOne in the next step.

Authentication and certificate lifetime​

Teleport enforces a hard ~30 hour upper bound on user-certificate TTL (apidefaults.MaxCertDuration in the Teleport source; max_session_ttl on roles cannot push past this ceiling — see this discussion). A --ttl=24h identity is fine for a trial, one-off ingestion, or demo, but the integration will stop authenticating once the certificate expires.

For any long-running deployment, follow Teleport's recommendation and provision credentials through Machine ID (tbot) rather than a static tctl auth sign identity. tbot joins the cluster with a delegated token (AWS IAM, GCP, Kubernetes, static token, etc.), continuously renews short-lived certificates, and writes a fresh identity file to disk that can be fed back into the integration on each run. This is the only approach that supports unattended operation beyond the 30h cap.

Configuration in JupiterOne​

  1. Navigate to the Integrations tab in JupiterOne and select Teleport.
  2. Click New Instance to begin configuring your integration and provide the following:
    • Account Name used to identify the Teleport cluster in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.
    • Description to assist in identifying the integration instance, if desired.
    • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.
    • Proxy Address — the public address of the Teleport Proxy Service with the port, e.g. cluster.teleport.sh:443.
    • Identity File — upload jupiterone-identity.pem from the previous step. JupiterOne stores the full PEM bundle as a masked secret.

Click Create once all values are provided to finalize the integration.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.