# Teleport Explained: Secure Infrastructure Access with Short-Lived Credentials

Source: https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access
Language: en
Published: 2026-10-17
Updated: 2026-10-17

Teleport explained: architecture, SSH, Kubernetes, databases, short-lived certificates, RBAC, audit, and edition boundaries.

Teleport is an access layer for infrastructure. It connects human and non-human identities to Linux servers, Kubernetes clusters, databases, and internal applications. Its core is not a single proxy but a system of certificate authorities, roles, resource services, audit data, and defined trust relationships.

## Short answer: what does Teleport do?

Teleport centralizes authentication, authorization, and routing for infrastructure access. After successful authentication, users or workloads receive short-lived credentials. Roles and resource labels then determine which targets, logins, and protocols are reachable.

Teleport is neither a directory service nor automatically the central identity provider. FreeIPA or Red Hat IdM can manage identities and Linux policies; Keycloak can provide web SSO and federation; Teleport controls access to enrolled infrastructure.

## Why traditional access models become difficult to scale

Permanently distributed SSH keys, bastion hosts with shared accounts, and separate access tools for every platform complicate rotation, revocation, and traceability. The problem is not SSH itself but the absence of one lifecycle for identity, authorization, and audit.

- Static keys often remain valid longer than the original need.
- Permissions are distributed across authorized\_keys, local accounts, Kubernetes RBAC, database roles, and application configuration.
- Offboarding must reach several independent systems in time.
- Bastion hosts do not automatically record the business identity behind every session.
- Emergency access becomes a standing privileged side path without a runbook.

## Architecture: Auth Service, Proxy Service, and resource services

The Auth Service is the trust root of the cluster. It manages Teleport certificate authorities, roles, users, other configuration resources, and the audit log. Its backend therefore contains security-critical cluster state and belongs in backup, recovery, and high-availability planning.

The Proxy Service is the client entry point and routes connections through reverse tunnels to enrolled services. Resource services provide protocol-specific access such as SSH, Kubernetes, Database, or Application Access. A demo can combine Auth and Proxy in one process; production designs need separate scaling and failure boundaries.

## Authentication and authorization are separate steps

Authentication establishes identity. Authorization then decides what that identity may do. Teleport roles can restrict logins, Kubernetes groups, database users, applications, and resource labels. Short certificate lifetimes do not automatically correct overly broad roles.

According to the Teleport 18.x feature matrix, Community supports GitHub SSO. OIDC and SAML, including the documented Keycloak integration, require Enterprise. An architecture using FreeIPA, Keycloak, and Teleport is therefore possible but neither mandatory nor edition-independent.

## Which resources can Teleport protect?

- SSH Access for Linux servers and agentless OpenSSH integrations.
- Kubernetes Access for controlled Kubernetes API connections and traceable sessions.
- Database Access for supported database protocols, roles, and audit events.
- Application Access for internal HTTP, web, and TCP applications.
- Machine & Workload Identity for short-lived automation and service identities.

## Short-lived certificates and credential lifecycle

Teleport operates its own certificate authorities and issues time-limited SSH or X.509 certificates. Their lifetime limits the exposure window of a stolen credential. Issuance, renewal, revocation, role changes, and target trust chains still require deliberate planning.

A human tsh login is not a robust solution for unattended automation. Teleport Machine & Workload Identity uses tbot to provision and renew workload credentials. Bootstrap, attestation, external PKI, and hardware-backed capabilities differ by edition and must be verified feature by feature.

## Audit and session recording

Teleport emits structured audit events and can record and replay interactive sessions. Captured content depends on protocol and recording mode. Retention, export, privacy, storage growth, and failure behavior of the recording path belong in operational acceptance.

## Separating Community and Enterprise

- Community: core access services, RBAC, structured audit logs, and session recording are generally available.
- Community: external SSO is limited to GitHub in the current matrix; roles can be requested through the CLI.
- Enterprise: OIDC and SAML, including the documented Keycloak integration.
- Enterprise Identity Governance: comprehensive just-in-time access requests, reviews, access lists, and related workflows.
- Enterprise: additional security, compliance, hardware, and availability features depending on product and deployment model.

## Common use cases

Teleport is particularly relevant when several infrastructure types need one controlled entry point, when static credentials should be reduced, or when sessions and access decisions must be traceable. A carefully managed SSH and FreeIPA model may still be appropriate for a small Linux-only environment.

## Integration with FreeIPA, Red Hat IdM, and Keycloak

One possible chain is: FreeIPA or Red Hat IdM manages users and groups; Keycloak federates this identity source and provides SSO; Teleport Enterprise consumes OIDC or SAML and maps claims to Teleport roles; those roles control infrastructure access. Claim mapping, MFA, failure behavior, and offboarding must be tested end to end.

## Operations and recovery

1. Define the edition, resources, trust boundaries, and failure objectives.
2. Design Auth, Proxy, and agent topology together with network paths and TLS.
3. Start with minimal roles and validate them using separate test identities.
4. Define audit and session storage, export, and retention.
5. Test upgrades, backup, restore, and break-glass in an isolated environment.
6. Only then migrate existing SSH, Kubernetes, or database access in controlled stages.

## Technical acceptance

- Authentication, role resolution, and resource labels have been tested with at least two separate roles.
- Allowed and explicitly denied access produce the expected results.
- Certificate lifetime, renewal, and revocation are documented and traceable.
- Audit events and session recordings are complete, readable, and protected.
- Failure of Proxy, Auth, or recording has been assessed against the target design.
- Break-glass, backup, and restore have owners and a practically testable recovery path.
- Community and Enterprise assumptions have been checked against the feature matrix current at rollout time.

## Next steps

The next practical learning steps are a reproducible SSH lab with session recording, followed by an Enterprise-validated Keycloak integration. The corresponding ForgeOne guides remain unpublished until those tests are fully documented.

## Hero image

[![Architecture illustration of a central access layer between identities and infrastructure resources](https://forgeone.solutions/media/teleport-infrastructure-access-hero.webp)](https://forgeone.solutions/media/teleport-infrastructure-access-hero.webp)

## Author

Mathias Rumbold

## Category

- [Identity & Access](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?category=identity-access)

## Tags

- [Security](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?tags=security)
- [Linux](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?tags=linux)
- [SSH](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?tags=ssh)
- [kubernetes](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?tags=kubernetes)
- [Automation](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?tags=automation)
- [Teleport](https://forgeone.solutions/en/tech/teleport-secure-infrastructure-access?tags=teleport)

## Links and sources

- [Teleport Feature Matrix 18.x](https://goteleport.com/docs/feature-matrix/)
- [Teleport Core Concepts](https://goteleport.com/docs/core-concepts/)
- [Teleport Architecture](https://goteleport.com/docs/reference/architecture/)
- [Teleport Ansible Integration](https://goteleport.com/docs/connect-your-client/third-party/ansible/)
- [Teleport Kubernetes Access](https://goteleport.com/docs/enroll-resources/kubernetes-access/)

## Assess your Teleport architecture

We assess resources, identity landscape, edition, and operating model for your specific use case.

[Discuss your project](https://forgeone.solutions/en/contact#book-appointment)

## Further content

- [Teleport](https://forgeone.solutions/en/products/teleport)
- [Identity & Access with Open Source and Enterprise Platforms](https://forgeone.solutions/en/products/identity-access)
- [Keycloak](https://forgeone.solutions/en/products/keycloak)
- [FreeIPA](https://forgeone.solutions/en/products/freeipa)
- [Ansible](https://forgeone.solutions/en/products/ansible)