Experience unparalleled security and ease in managing GitHub with Teleport.
Protect your data like never before!
Teleport integrates with GitHub in multiple ways:
Each integration maps GitHub identity to Teleport’s unified identity layer, which enforces least privilege and eliminates static credentials across all human, machine, and AI identities, recording all sessions and collecting audit events for every authenticated connection.
Using GitHub as an SSO provider lets your engineers log in to Teleport with their existing GitHub account, allowing you to govern access by mapping GitHub teams to Teleport roles. Authorization mirrors your GitHub org instead of living in a separate directory.
For the complete, step-by-step walkthrough, including GitHub Enterprise settings and troubleshooting, follow the official guide: Set up Single Sign-On with GitHub.
CI pipelines are commonly dependent on long-lived credentials like static tokens or keys be that are stored as a repository secret and are difficult to contain once leaked. Teleport eliminates problem by issuing GitHub Actions their own cryptographic identity and issuing short-lived certificates at job runtime, enabling pipelines to reach protected resources without long-lived credentials.
A workflow authenticates using GitHub's native OpenID Connect (OIDC) token, which Teleport verifies against the job's identity (repository, branch, environment) and exchanges for an ephemeral certificate. The certificate is valid only for the run and expires when the job finishes, leaving no static secrets in the repository to steal or standing privileges.
This works on GitHub-hosted runners, self-hosted runners, and GitHub Enterprise Server. For a closer look at how this works, read our GitHub Actions deployment documentation. To see what this looks like in practice, read our blog on Machine ID and GitHub Actions without long-lived secrets.
Learn more about Teleport Machine & Workload Identity.
Teleport's built-in certificate authority replaces static SSH keys with short-lived certificates tied to a verified GitHub identity. After an engineer authenticates through GitHub SSO, Teleport issues an SSH certificate that contains the user's permissions and an expiration timestamp, removing the need to distribute, track, or rotate SSH keys across the fleet. Every SSH session is governed by role-based access control and recorded to an audit log that can be replayed.
If you use GitLab as well, see the related GitLab integration for the equivalent SSO and machine identity paths.
Can I use GitHub as an SSO provider for Teleport?
Yes. Teleport supports GitHub as an identity provider for single sign-on. You register a GitHub OAuth application, create a Teleport GitHub authentication connector, and map GitHub teams to Teleport roles so authorization follows your existing org structure.
How do I map GitHub teams to Teleport roles?
In the GitHub authentication connector, the teams_to_roles field maps each GitHub organization and team to one or more Teleport roles. A member of a mapped team receives exactly the access those roles grant, keeping authorization least-privilege.
How does Teleport secure GitHub Actions without long-lived credentials?
Teleport Machine and Workload Identity verifies the GitHub Actions OIDC token and issues a short-lived certificate scoped to that job. The certificate expires when the run finishes, so there is no static secret stored in the repository to leak.
Does Teleport replace static SSH keys?
Yes. Teleport's built-in certificate authority issues short-lived SSH certificates tied to GitHub identity and roles, replacing static keys. Certificates expire automatically, and every session is governed by RBAC and written to an immutable audit log.
Where is the full GitHub SSO setup guide?
The complete, step-by-step walkthrough is in the Teleport documentation: Set up Single Sign-On with GitHub, at goteleport.com/docs/zero-trust-access/sso/integrate-idp/github-sso/.