Teleport ist eine Zugriffsschicht für Infrastruktur. Die Plattform verbindet menschliche und nichtmenschliche Identitäten mit Linux-Servern, Kubernetes-Clustern, Datenbanken und internen Anwendungen. Der Kern besteht nicht aus einem einzelnen Proxy, sondern aus Certificate Authorities, Rollen, Ressourcendiensten, Auditdaten und definierten Vertrauensbeziehungen.
Kurzantwort: Welche Aufgabe übernimmt Teleport?
Teleport zentralisiert Authentifizierung, Autorisierung und Routing für Infrastrukturzugriffe. Nach erfolgreicher Anmeldung erhalten Benutzer oder Workloads kurzlebige Zugangsdaten. Rollen und Ressourcenlabels bestimmen anschließend, welche Zielsysteme, Logins und Protokolle erreichbar sind.
Teleport ist dabei weder ein Directory Service noch automatisch der zentrale Identity Provider. FreeIPA oder Red Hat IdM können Identitäten und Linux-Policies verwalten; Keycloak kann Web-SSO und Federation bereitstellen; Teleport kontrolliert den Zugriff auf die angebundene Infrastruktur.
Warum klassische Zugriffsmodelle schwer skalieren
Dauerhaft verteilte SSH-Schlüssel, Bastion Hosts mit gemeinsamen Konten und getrennte Zugriffslösungen pro Plattform erschweren Rotation, Entzug und Nachvollziehbarkeit. Das Problem ist nicht SSH selbst, sondern der fehlende gemeinsame Lebenszyklus für Identität, Berechtigung und Audit.
Statische Schlüssel bleiben oft länger gültig als der ursprüngliche Bedarf.
Berechtigungen verteilen sich auf authorized_keys, lokale Konten, Kubernetes-RBAC, Datenbankrollen und Anwendungskonfigurationen.
Ein Offboarding muss mehrere voneinander unabhängige Systeme rechtzeitig erreichen.
Bastion Hosts protokollieren nicht automatisch die fachliche Identität hinter jeder Sitzung.
Notfallzugänge werden ohne Runbook schnell zum dauerhaft privilegierten Nebenweg.
Architektur: Auth Service, Proxy Service und Ressourcendienste
Der Auth Service ist die Vertrauenswurzel des Clusters. Er verwaltet die Teleport Certificate Authorities, Rollen, Benutzer und weitere Konfigurationsressourcen und führt das Audit Log. Sein Backend enthält deshalb sicherheitskritischen Clusterzustand und muss in Backup-, Recovery- und Hochverfügbarkeitskonzepte einbezogen werden.
Der Proxy Service bildet den Zugangspunkt für Clients und vermittelt Verbindungen über Reverse Tunnels zu den angebundenen Diensten. Ressourcendienste stellen den protokollspezifischen Zugriff bereit, beispielsweise SSH, Kubernetes, Database oder Application Access. Eine Demo kann Auth und Proxy in einem Prozess kombinieren; Produktionsdesigns müssen Skalierung und Ausfallgrenzen getrennt betrachten.
Authentifizierung und Autorisierung sind getrennte Schritte
Authentifizierung weist nach, wer eine Identität ist. Autorisierung entscheidet danach, was diese Identität tun darf. Teleport-Rollen können erlaubte Logins, Kubernetes-Gruppen, Datenbankbenutzer, Anwendungen und Ressourcenlabels begrenzen. Kurze Zertifikatslaufzeiten verhindern jedoch nicht automatisch zu breite Rollen.
Community unterstützt laut Teleport-18.x-Feature-Matrix GitHub SSO. OIDC und SAML, darunter die dokumentierte Anbindung von Keycloak, gehören zu Enterprise. Eine Architektur mit FreeIPA, Keycloak und Teleport ist daher möglich, aber weder in jeder Umgebung nötig noch editionsunabhängig.
Welche Ressourcen schützt Teleport?
SSH Access für Linux-Server und agentlose OpenSSH-Integrationen.
Kubernetes Access für kontrollierte Verbindungen zur Kubernetes API und nachvollziehbare Sitzungen.
Database Access für unterstützte Datenbankprotokolle, Rollen und Auditereignisse.
Application Access für interne HTTP-, Web- und TCP-Anwendungen.
Machine & Workload Identity für kurzlebige Identitäten von Automatisierung und Diensten.
Kurzlebige Zertifikate und Credential Lifecycle
Teleport betreibt eigene Certificate Authorities und stellt zeitlich begrenzte SSH- beziehungsweise X.509-Zertifikate aus. Die Laufzeit begrenzt das Zeitfenster eines gestohlenen Credentials. Zusätzlich müssen Ausgabe, Erneuerung, Widerruf, Rollenänderungen und die Vertrauenskette der Zielsysteme geplant werden.
Für unbeaufsichtigte Automation ist ein menschlicher tsh-Login keine belastbare Lösung. Teleport Machine & Workload Identity verwendet tbot, um Credentials für Workloads bereitzustellen und zu erneuern. Bootstrap, Attestation, externe PKI und Hardwarefunktionen unterscheiden sich nach Edition und müssen funktionsgenau geprüft werden.
Audit und Session Recording
Teleport erzeugt strukturierte Auditereignisse und kann interaktive Sitzungen aufzeichnen und wiedergeben. Welche Inhalte erfasst werden, hängt vom Protokoll und Aufzeichnungsmodus ab. Aufbewahrung, Export, Datenschutz, Speicherwachstum und das Verhalten bei einem Ausfall des Recording-Pfads gehören in die Betriebsabnahme.
Community und Enterprise korrekt abgrenzen
Community: zentrale Access-Dienste, RBAC, strukturierte Audit Logs und Session Recording sind grundsätzlich verfügbar.
Community: externes SSO ist in der aktuellen Matrix auf GitHub begrenzt; Rollen können per CLI angefordert werden.
Enterprise: OIDC und SAML sowie damit die dokumentierte Keycloak-Anbindung.
Enterprise Identity Governance: umfassende Just-in-Time Access Requests, Reviews, Access Lists und weitere Workflows.
Enterprise: zusätzliche Sicherheits-, Compliance-, Hardware- und Hochverfügbarkeitsfunktionen je Produkt und Deployment-Modell.
Typische Einsatzszenarien
Teleport eignet sich besonders, wenn mehrere Infrastrukturtypen einen gemeinsamen kontrollierten Einstieg benötigen, wenn statische Zugangsdaten reduziert werden sollen oder wenn Sitzungen und Entscheidungen nachvollziehbar sein müssen. Für eine einzelne kleine Linux-Umgebung kann ein sauber gepflegtes SSH- und FreeIPA-Modell weiterhin angemessen sein.
Integration mit FreeIPA, Red Hat IdM und Keycloak
Eine mögliche Kette lautet: FreeIPA oder Red Hat IdM verwaltet Benutzer und Gruppen; Keycloak föderiert diese Identity Source und stellt SSO bereit; Teleport Enterprise übernimmt OIDC oder SAML und ordnet Claims Teleport-Rollen zu; die Rollen steuern den Zugriff auf Infrastrukturressourcen. Diese Kette muss Claim-Mapping, MFA, Ausfallverhalten und Offboarding durchgängig testen.
Betrieb und Recovery
Edition, Ressourcen, Trust Boundaries und Ausfallziele festlegen.
Auth-, Proxy- und Agent-Topologie samt Netzwerkpfaden und TLS planen.
Rollen zunächst minimal modellieren und mit Testidentitäten abnehmen.
Audit- und Session-Speicher, Export und Aufbewahrung definieren.
Upgrade, Backup, Restore und Break-glass in einer isolierten Umgebung testen.
Erst danach bestehende SSH-, Kubernetes- oder Datenbankzugriffe kontrolliert migrieren.
Technische Abnahme
Authentifizierung, Rollenauflösung und Ressourcenlabels sind mit mindestens zwei getrennten Rollen getestet.
Erlaubte und ausdrücklich verbotene Zugriffe liefern die erwarteten Ergebnisse.
Zertifikatslaufzeit, Erneuerung und Entzug sind nachvollziehbar dokumentiert.
Auditereignisse und Session Recordings sind vollständig, lesbar und geschützt abgelegt.
Ausfall von Proxy, Auth oder Recording wurde entsprechend dem Zielbild bewertet.
Break-glass, Backup und Restore besitzen Verantwortliche und einen praktisch prüfbaren Rückweg.
Community-/Enterprise-Annahmen sind gegen die beim Rollout aktuelle Feature-Matrix geprüft.
Wie es weitergeht
Die nächsten praxisorientierten Lernschritte sind ein reproduzierbarer SSH-Labaufbau mit Session Recording und anschließend eine Enterprise-validierte Keycloak-Integration. Bis diese Tests vollständig dokumentiert sind, bleiben die zugehörigen ForgeOne-Anleitungen unveröffentlicht.
