© Eugenio Marongiu / 123RF.com

Teleport verwaltet Logins verschiedener Protokolle, darunter SSH, Kubernetes sowie diverse Datenbanken von zentraler Stelle. Funktionen wie Zwei-Faktor-Authentifizierung gehören dabei ebenso zum Lieferumfang wie das Verwalten eigener Zertifikate.

Wehmütig mag sich mancher Admin an die Zeiten erinnern, in denen die Anzahl seiner Zugänge und Passwörter übersichtlich ausfiel. Vor anderthalb Jahrzehnten waren Security und Compliance vielerorts noch nicht so dominant wie heute, und mancher Admin verzichtete auf seinen ausschließlich per SSH zu erreichenden Maschinen zugunsten von Root gleich ganz auf lokale Accounts. Stattdessen gab es ein Passwort für Root, das überall im Setup funktionierte und – mit viel Glück – irgendwo in einem zentralen Passwortspeicher verschlüsselt abgelegt war. Meistens konnte man sich diese Passwörter allerdings so einfach merken, dass ein Abspeichern ohnehin überflüssig war.

Aus heutiger Sicht ist das zum Glück völlig undenkbar. Zertifizierungen wie jene des BSI oder PCI-DSS schreiben vor, dass es möglich sein muss nachzuvollziehen, wer wann was auf welchen Systemen geändert hat, sodass individuelle Accounts Pflicht sind. Selbst die härtesten Leugner der Notwendigkeit von Compliance lassen sich heute nicht mehr dazu hinreißen, sich per SSH als Root und mit Passwort einzuloggen. Die meisten Distributionen verbieten das in der Standardkonfiguration sogar. Sudo und SSH-Schlüssel für individuelle Zugänge sind stattdessen die Mittel der Wahl.

Login-Chaos

Dagegen spricht auch nichts, gerade nicht in Setups, in denen Admins tatsächlich nur mit dem Betrieb und der Wartung von per SSH erreichbaren Maschinen betraut sind. Das ist heute aber immer seltener der Fall. DevOps, die Cloud und Container haben die IT stattdessen viel heterogener gemacht: Kubernetes-APIs und Datenbanken brauchen Credentials, diverse andere Dienste ebenso, und alle nutzen ihr eigenes Protokoll zur Authentifizierung.

Selbst in Sachen SSH sind die Dinge nicht ganz so klar, wie sie im ersten Augenblick scheinen: Im Interesse der Sicherheit ist es heute nämlich durchaus üblich, Systeme nicht mehr mit direktem Anschluss an das Internet zu betreiben, falls diese den Zugriff nicht brauchen. Suse Manager, Red Hat Satellite und Konsorten haben längst eine Lösung für das Problem gefunden, Systeme ohne direkten Internet-Anschluss mit Updates und allen anderen notwendigen Funktionen zu versorgen.

Im Gegenzug lassen sich solche Systeme dann aber freilich auch nicht mehr mittels SSH direkt erreichen. Stattdessen kommen ein Jumphost oder eine Cluster-Workstation zum Einsatz, die als zentraler Zugangspunkt dienen und von denen aus der Admin sich zum eigentlichen Zielsystem weiterhangelt. Dazu muss er sich allerdings Abfolgen von Hosts merken, die zum Ziel führen. Wer schon einmal am Sonntagmorgen um halb drei aus dem Schlaf gerissen wurde, weil im Rechenzentrum ein Server Amok lief, der weiß, dass das Hirn in solchen Situationen nicht unbedingt sofort auf Betriebstemperatur kommt.

Teleport hilft

Genervten Admins steht Teleport [1] zur Seite, und zwar mit mehreren Versprechen. So gehört das Chaos mit verschachtelten SSH-Jumphosts bei Teleport laut dessen Entwicklern der Vergangenheit an. Obendrein will Teleport die Authentifizierung in SSH innerhalb der Grenzen eines Setups standardisieren. Dazu setzt es auf eine eigene SSL-CA und X.509-Zertifikate anstelle einfacher SSH-Schlüssel, die es bei Bedarf selbst ausgibt und auch widerruft. Zusätzlich unterstützt Teleport das Login per Benutzernamen und Passwort, fügt hier jedoch eine Authentifizierung mit zwei Faktoren hinzu, die in SSH mit Bordmitteln nur schwer zu erreichen ist.

Das eigentliche Killer-Feature der Software ist allerdings ein anderes: Teleport nutzt SSH bei Bedarf auch als Tunnelprotokoll, um den Admin mit anderen Diensten wie Kubernetes, den gängigen Datenbanken und weiteren Diensten zu verbinden. Aus dem eigentlichen SSH-Server wird mithin ein Multitalent der Konnektivität, das dem Admin die Sorgen mit Authentifizierung und Autorisierung abzunehmen verspricht. Ob das klappt und welche Funktionen Teleport bietet, verrät dieser Artikel.

Die Teleport-Architektur

Zunächst fördert es das Verständnis jedoch ungemein, sich die Teleport-Architektur zu vergegenwärtigen (Abbildung 1). Unter der Haube besteht eine Teleport-Instanz eigentlich aus drei autarken Diensten. Diese sind Teil desselben Binarys, Teleport kommt also als einzelne, große Go-Datei daher. Obendrein unterstützen die einzelnen Teile von Teleport den Betrieb im Cluster-Modus, technisch notwendig ist das allerdings nicht.

Abbildung 1: Teleport besteht im Kern aus drei Komponenten: dem Proxy, der Authentifizierungs- und der Node-Komponente. Alle Knoten, auf denen ein Teleport-Node läuft, bilden zusammen einen Cluster als logische Einheit.

Zunächst spielt der Teleport-Proxy eine bedeutende Rolle. Er lauscht an der Außenseite nach eingehenden Verbindungen und dient als eigentlicher SSH-Server, spricht also das SSH-Protokoll. Empfängt er eine eingehende Verbindung eines Clients, kommuniziert er zunächst im Hintergrund mit dem meist als Authentication-Komponente oder einfach Auth abgekürzten Teil. Die Frage, ob ein Client Zugriff auf ein Zielsystem erhält, entscheidet sich dort: Die Auth-Komponente ist zugleich nämlich auch eine vollständige SSL-Certificate-Authority (CA).

Meldet ein Client sich bei der Auth-Komponente direkt mit einem validen X.509-Schlüssel an, den die Auth-Komponente selbst ausgestellt hat, tritt die Verbindung zum Zielsystem in die nächste Phase ein. Nutzt der Client stattdessen eine Kombination aus Passwort und Benutzernamen, erstellt die Auth-Komponente zunächst ein gültiges X.509-Zertifikat mit eingeschränkter Gültigkeit (üblicherweise 12 Stunden) und spielt es an den Client zurück. Dann folgt die zweite Phase des Verbindungsaufbaus.

In der kommt Teleport im Node-Modus zum Einsatz. Auf jedem Knoten eines Teleport-Clusters läuft Teleport im Node-Modus ebenfalls als SSH-Server, und sobald der Client mit einem gültigen X.509-Zertifikat ausgestattet ist, baut er durch den Teleport-Proxy hindurch die Verbindung mit dem Zielsystem auf. Hier steht dem Client dann eine Shell zur Verfügung, so wie es in Setups ohne Teleport auch der Fall wäre.

Der versierte Admin, der grundlegenden Neuerungen stets zurückhaltend gegenübersteht, rümpft an dieser Stelle womöglich die Nase. Schließlich ist der Austausch von OpenSSH, das viele Admins kennen und schätzen, ein invasiver Eingriff im Hinblick auf die gesamte Architektur eines Systems – und so viel Mehrwert bietet Teleport auf den ersten Blick nicht. X.509-Zertifikate lassen sich schließlich auch mit dem normalen SSH verwenden. Um die praktische Relevanz von Teleport zu verstehen, lohnt sich ein genauerer Blick auf die diversen Features, die Teleport in Setups einbringt.

Teleport kann mehr

Da ist zunächst das Handling von SSL-Zertifikaten. Zwar vermag auch OpenSSH sich anhand einer bestehenden SSL-CA von Clients zugesandte Zertifikate anzuschauen und zu bewerten. Das gesamte Handling der CA obliegt in einem solchen Setup allerdings dem Administrator – und jeder Admin, der schon einmal eine SSL-CA an der Backe hatte, kann die Komplexität dieses Unterfangens aus eigener Erfahrung beurteilen.

Teleport nimmt dem Admin hier also zumindest schon einmal einiges an Arbeit ab. Es leistet aber noch mehr: Weil es die Handhabung von Zertifikaten automatisiert, trägt es obendrein zur Sicherheit bei, indem es die Gültigkeit etwaiger Zertifikate beschränkt. Die von Teleport ausgestellten Zertifikate gelten maximal zwölf Stunden. Selbst, wenn sie in falsche Hände geraten, lässt sich der Schaden also eingrenzen.

Hinzu kommt, dass Teleport das gesamte Handling von Zertifikaten vor den Augen der Nutzer weitgehend versteckt. Mit den Befindlichkeiten von SSL muss sich der Admin nur beim initialen Setup befassen; ist Teleport im Tritt, funktioniert der Rest von allein. Das erleichtert den administrativen Alltag enorm.

2FA ist wichtig

Nicht unterschätzen sollte man daneben den Gesichtspunkt der Authentifizierung mit zwei Faktoren, der in dieser Form für Teleport einmalig ist. Die allermeisten Setups, die auf SSH setzen, bieten keine Unterstützung für einen zweiten Faktor; das klassische Setup auf Basis von SSH-Schlüsseln beherrscht 2FA nur mit zusätzlichen Basteleien. Das ist bei Teleport anders, denn hier ist die Zwei-Faktor-Authentifizierung essenzieller Teil des gesamten Authentifizierungsvorgangs.

Mit hinein spielt dabei, dass Teleport den Teil mit den X.509-Zertifikaten vor den Augen der Nutzer versteckt: Die müssen sich bei Teleport mit den technischen Details des Zertifikats-Handlings nicht auskennen. Sie verwenden stets einen separaten Client für das Login, die Teleport-Shell, bei der sie sich mit Benutzernamen, Passwort und zweitem Faktor anmelden. Das Ausstellen des spezifischen SSL-Zertifikats für den jeweiligen Client geschieht dann im Hintergrund. Faktisch ist Teleport damit ab Werk deutlich sicherer als normales, schlüsselbasiertes SSH.

Zugang zu weiteren Diensten

Damit erschöpft sich die Liste der Teleport-Vorteile allerdings noch lange nicht. Auf dem Markt einzigartig ist, dass Teleport nicht nur als SSH-Server fungieren kann, sondern auch als Gateway für beliebige Protokolle in beliebige Richtungen. Davon profitiert zuvorderst wieder SSH.

Das eingangs erwähnte Beispiel der Verbindungen über mehrere Jumphosts lässt sich in Teleport beispielsweise sehr leicht implementieren. Teleport greift im Hintergrund auf eine eigene Liste von Maschinen zurück, die zum gesamten Setup gehören. Die Entwickler benutzen hierfür den Begriff Cluster: Jede Maschine, auf der der Teleport-Node-Dienst läuft, gehört zum selben Cluster. Die von Teleport ausgestellten SSL-Zertifikate etwa gelten Cluster-weit, sodass ein einmal authentifizierter Nutzer in seinem Client mit dem Zertifikat indirekt Zugriff auf alle verfügbaren Ressourcen erhält.

In Sachen Node Discovery beherrscht Teleport mehrere Mechanismen. Ganz klassisch lassen sich Teleport-Nodes mittels DNS sammeln. Der Weisheit letzter Schluss ist das aber nicht, denn Teleport bringt ein eigenes Discovery-Protokoll mit (Abbildung 2). Es weist unter der Haube deutlich mehr Komplexität auf, als man vermuten würde.

Abbildung 2: Teleport kommt auf der Proxy-Ebene mit einem eigenen Protokoll für die Erkennung von Knoten daher, sodass komplexe Jumphost-Setups der Vergangenheit angehören. Quelle: Teleport

Die bereits erwähnten Proxy-Server spielen dabei eine wichtige Rolle, denn von ihnen kann es mehr als eine Instanz geben – Hochverfügbarkeit ist bei Teleport schließlich essenzieller Bestandteil des Konzepts. Proxy-Server aus demselben Cluster kommunizieren miteinander und tauschen Informationen über die Zielsysteme aus, die sie sehen. Sehen bedeutet im konkreten Fall, dass auf einem Knoten die Teleport-Node-Komponente aktiv ist: Installiert der Admin sie auf einem Zielsystem, fügt er sie mittels separater Befehle zum existierenden Cluster hinzu, wobei er mindestens einen der bestehenden Proxy-Server als Ziel für das Join-Kommando angibt.

Danach kann jedes Zielsystem mit jedem Proxy-Server sprechen, und auf diese Weise lassen sich die Teleport-Proxy-Server bequem schachteln: Proxy 1 bekommt vom Leaf-Proxy 1 dann die Information über alle sichtbaren Knoten und teilt sie mit den anderen vorhandenen Teleport-Proxies. Ein Client, der sich mit einem Zielsystem verbinden möchte, muss daher lediglich dessen IP-Adresse oder den Hostnamen kennen. Welchen Weg er durch ein Gestrüpp von geschachtelten Netzen nehmen muss, um ans Ziel zu gelangen, braucht der Anwender sich hingegen nicht mehr zu merken: Diesen Pfad machen der Teleport-Client und der Proxy, zu dem der Client sich im ersten Schritt verbindet, dynamisch untereinander aus.

Das ist gerade im Kontext von Hochverfügbarkeit sehr praktisch: Schaltet der Admin seinen Teleport-Proxies einen Load Balancer vor, muss der Client sich nur eine Adresse merken und darf sicher sein, von jedem der dahinter laufenden Proxies aus jeden anderen Host im Setup zu erreichen. In modernen Setups, die sich in mehrere DMZs und Netzwerksegmente unterteilen und umfangreiche Sicherheitsmaßnahmen implementieren, bringt das einen enormen Gewinn in Sachen Komfort.

Security und Compliance

Die eingebaute Zertifikatsverwaltung und die Lösung des Jumphost-Problems wären als Mehrwert gegenüber handelsüblichen Lösungen bereits genug, um den Einsatz von Teleport zu rechtfertigen. Allerdings erschöpfen sich die Vorteile des Diensts hier noch lange nicht. Von großer Bedeutung ist beispielsweise auch, dass sich die Teleport-Entwickler um die Themen Sicherheit und Compliance viele Gedanken gemacht haben.

Wer Teleport etwa in einer Umgebung betreibt, die mit hochsensiblen Daten hantiert, unterliegt womöglich zusätzlich einer strengen Gesetzgebung. Auf dem Heimatmarkt von Teleport zählt dazu etwa der Health Insurance Portability and Accountability Act (HIPAA), der strenge Standards für den Umgang mit Gesundheitsdaten in den USA definiert. Wer sich mit Compliance-Legislatur bereits beschäftigt hat, findet im HIPAA viele Vorgaben und Richtlinien, die auch hierzulande in einschlägigen Regelungen stehen, allen voran in der DSGVO.

Teleport ist nach den Regeln des HIPAA offiziell zertifiziert. Hierzulande jedoch viel wichtiger dürfte die ebenfalls vorhandene Zertifizierung nach den Regeln der SOC-2-Richtlinie sein. Die klammert sich nämlich nicht an spezifische amerikanische Gesetze, sondern gilt in der Industrie als akzeptierter Standard für Anwendungen mit Bezug zu sicherheitsrelevanten Daten. Anders formuliert: Wer Teleport in einer Umgebung nutzt, hat weniger Aufwand, diese etwa im Rahmen einer BSI-Zertifizierung zu beschreiben, weil der entsprechende Report dafür seitens der Teleport-Entwickler bereits zur Verfügung steht.

eBPF schreibt mit

Besondere Beachtung in Teleport verdient ein Faktor, der sich in der Dokumentation sehr zu unrecht quasi unter “ferner liefen” findet: Teleport bietet auf den Systemen, auf denen es läuft, umfassende Auditing- und Logging-Möglichkeiten, die in anderen Lösungen so kaum existieren.

Zunächst erfüllt Teleport dabei Aufgaben, die sich aus der Architektur der Lösung ergeben. Wenn eine Komponente die zentrale Verwaltung von Logins verantwortet, fällt es ihr leicht, Protokoll über die tatsächlich geschehenen Logins zu führen. Teleport nennt das Audit Log: Die Lösung schreibt also mit, wer sich zu welchem Zeitpunkt von wo kommend auf welchem Server des Teleport-Clusters eingeloggt hat (Abbildung 3). Die Information stellt der Dienst danach als strukturierte JSON-Datei zur Verfügung, die sich auch außerhalb von Teleport gut in verschiedenen Diensten verarbeiten lässt.

Abbildung 3: Teleport loggt auf mehreren Wegen Befehle und Traffic, den es sieht – die Audit-Logs bilden dabei die grundlegendste Logging-Form.

Freilich sollten Log-Daten dieser Art auch an einer externen Stelle zur Verfügung stehen, weil nach einem erfolgreichen Angriff möglicherweise nur noch manipulierte Protokolle vorhanden sind. Anhand einer externen Datenquelle lässt sich gegebenenfalls zumindest noch der Zeitpunkt des Hacks ermitteln, was die Forensik erleichtert. Allerdings offeriert der Markt bisher kaum fertige Integrationen für die aus Teleport stammenden Log-Dateien, etwa für Loki oder den ELK-Stack aus Elasticsearch, Logstash und Kibana. Admins müssen sich mithin eine Integration des Audit-Logs aus Teleport für ihr spezifisches Log-System selbst bauen, falls die Funktionalität gewünscht ist.

Die Logging-Fähigkeiten von Teleport gehen über das Mitschreiben von Metadaten (Abbildung 4) über die tatsächlichen Verbindungen allerdings weit hinaus. Hier machen die Entwickler sich eine Technik zunutze, die der Linux-Kernel selbst anbietet und die brillant ist, in der F/LOSS-Welt jedoch bis heute zu wenig Aufmerksamkeit bekommt: eBPF.

Abbildung 4: In den Logs findet der Administrator hinterher strukturierte Logdateien im JSON-Format, die sich in anderen Systemen gut weiterverarbeiten lassen. Derzeit fehlt aber eine native Integration etwa in Loki oder ELK.

Zur Erinnerung: eBPF steht für Berkeley Packet Filter; das Thema war bereits mehrfach im Linux-Magazin prominent vertreten [2]. Faktisch handelt es sich bei eBPF um kleine, in Rust geschriebene virtuelle Maschinen, die sich in den laufenden Linux-Kernel laden lassen. Dort können sie beliebige Funktionen anhand einer definierten API implementieren. Wenn der Admin es entsprechend einrichtet, bekommt eBPF dabei kompletten Zugriff auf den Traffic Flow eines Systems oder einzelner Anwendungen. eBPF ist allerdings deutlich leistungsstärker als vergleichbare Packet Filter etwa auf der Basis von Nftables.

Mittlerweile finden sich auf dem Markt immer mehr Anwendungen, die eBPF nutzen. Google hat in Form seiner Kernel Runtime Security Instrumentation (KRSI) etwa ein Framework vorgestellt, das komplette Daten-Streams überwacht und an neuralgischen Stellen Checkpoints einrichtet, die Anwendungen das Unterbrechen von Traffic Flows ermöglichen. KRSI kombiniert dazu eBPF, das die eigentliche Funktionalität der Überwachung implementiert, mit dem Linux Security Framework, das Anwendungen wie SELinux und AppArmor in ähnlicher Weise verwenden. Der Mühe Lohn: Teleport lässt sich anhand vorgegebener Richtwerte dazu bringen, laufende Sessions automatisch zu beenden oder zu unterbrechen, wenn der Inhalt der übermittelten Information bestimmten Kriterien entspricht.

Datenabfluss verhindern

Ein Beispiel aus der Praxis macht das deutlicher. Hat ein Angreifer sich erst einmal Zugriff auf ein System verschafft, hindert ihn (wenn er Root ist) niemand mehr daran, Daten aus diesem System beliebig abzutransportieren. Viele Angreifer bleiben heute unter dem Radar, weil das eigentliche Angriffsziel zum Beispiel Datenbanken sind, die Kreditkartendaten und Passwörter enthalten. Das öffentliche Defacing von Websites steht nicht mehr im Fokus der meisten Ganoven. Aus Sicht des angegriffenen Unternehmens ist das unkontrollierte und ungewollte Abfließen von Daten allerdings ein deutlich größeres Problem, das je nach Land sogar empfindliche juristische Konsequenzen nach sich ziehen kann.

Hier wäre die dynamische Unterbrechung von Teleport hilfreich, zumindest unter der Voraussetzung, dass die Teleport-Proxy-Knoten nicht selbst einem Angriff zum Opfer fallen. Mittels der Restricted Session definiert der Admin Schlüsselwörter, die in den übertragenen Sitzungen nicht vorkommen sollten, und die Teleport automatisch dazu bringen, die Verbindung zu beenden. Konfigurieren lassen sich solche Schlüsselwörter über Teleports eigene API. Das funktioniert dynamisch, sodass der Admin etwa ein Keyword in einer versteckten Datenbankzeile hinterlegen könnte, auf das Teleport dann beim Transfer anspringt. Das genannte Beispiel bleibt freilich rudimentär – wer die Fähigkeiten von Teleport und eBPF ausreizen möchte, kommt um ein umfassendes Sicherheitskonzept und einige Entwicklungsarbeit kaum herum. Bemerkenswert ist jedoch, dass Teleport solche Setups überhaupt ermöglicht; Vergleichbares ließe sich mit OpenSSH und Nftables nicht realistisch umsetzen.

Die Logging-Features von Teleport greifen zudem auch in einem deutlich weniger invasiven Modus: Wer “nur” auf einen Audit Trail aus ist, kann Teleport den gesamten Datenverkehr von SSH-Sitzungen mitschreiben lassen. Manche Zertifizierungen gehen in Sachen Accountability mittlerweile so weit, das sie nicht mehr nur einzelne Accounts für einzelne Anwender fordern, sondern auch nachgewiesen haben wollen, wer auf einem System welche Befehle zu welchem Zeitpunkt ausgeführt hat.

Damit das Prinzip funktioniert, ist es freilich wichtig, die Teleport-Proxies von anderen Personen betreiben zu lassen als die Zielsysteme, denn Bösewichte könnten die selbst installierten Schutzmechanismen sonst leicht umgehen. Bei einer klaren Trennung der Verantwortlichkeiten eignet Teleport sich jedoch hervorragend, um die umfassenden Audit-Bedingungen diverser Zertifizierungen zu erfüllen.

Wer Teleport auf diese Weise in Deutschland einsetzt, sollte allerdings sicherstellen, nicht mit Datenschutzvorgaben im Arbeitsrecht zu kollidieren. Das wird etwas leichter, sieht man vom Logging und der Überwachung des Kommunikationsinhalts ab und beschränkt die Kommunikation stattdessen auf erlaubte Hosts. Auch das gelingt mit eBPF: Merkt der Filter, dass Pakete an eine nicht freigeschaltete IP fließen sollen, unterbricht er die Verbindung anwendungsspezifisch automatisch (Abbildung 5).

Abbildung 5: eBPF-Beispielcode, der so in Teleport zur Anwendung kommt und eine Verbindung unterbricht, falls Daten in unerwünschte IP-Netzwerke (»denylist«) abwandern. Quelle: Teleport

Kubernetes? Kein Problem!

Die bisher beschriebenen Vorteile für Teleport finden vorrangig unter der Haube statt, doch bietet Teleport auch offen sichtbare Features. Das markanteste davon ist zweifelsohne Teleports Fähigkeit, nicht nur für SSH als Tunnelagent zu fungieren, sondern auch für eine Vielzahl anderer Protokolle. Zwar war SSH die Keimzelle, und in der Teleport-Dokumentation findet sich auch heute noch vielerorts der Satz, dass Teleport im Kern ein SSH-Server sei. Mittlerweile versteht die Lösung sich aber eher als eine Art Mittler zwischen den Welten, wie ein paar Beispiele verdeutlichen.

Neben dem SSH-Protokoll beherrscht der Teleport-Proxy beispielsweise die API des Cluster-Flottenmanagers Kubernetes. Nach dem anfänglichen Login eines Benutzers beim Teleport-Proxy mittels »tsh login« baut »tsh« die Umgebungsvariablen des Benutzers so um, dass etwaige Anfragen etwa an Kubernetes oder PostgreSQL automatisch durch den Proxy-Server hin zum Zielsystem umgeleitet werden. Auf demselben System, auf dem der Admin also »ssh user@host« ausführt, um nach dem Login in der Shell von Teleport zu seinem Zielsystem zu kommen, wären anschließend also auch Befehle mittels Kubectl ausführbar oder »psql«, um sich mit PostgreSQL zu verbinden. Sogar für den RDP-basierten Zugriff auf Desktop-Systeme steht Teleport zur Verfügung (Abbildung 6).

Abbildung 6: Teleport ermöglicht den authentifizierten Zugriff auf VMs etwa in der Cloud, auf Wunsch im Team zusammen mit Azure Active Directory oder Azure Active Directory DS. Quelle: Teleport

Aus Sicht des Nutzers steigert diese Vielfältigkeit den Komfort beim Verwenden der Lösung nochmals: Musste man sich früher für jede einzelne Anwendung darum kümmern, die Authentifizierung richtig einzustellen, nimmt Teleport einem diese Arbeit einfach ab. Wer schon versucht hat, die Credentials für den Zugriff auf eine MySQL-Datenbank sinnvoll zu verwalten, wird seine ».myrc« irgendwann genervt in Ansible & Co. packen. Das ist allerdings alles andere als dynamisch und bedarf einer regelmäßigen Anpassung, falls Zugangsdaten sich ändern.

Anders bei Teleport: Indem der Admin die Datenbank so konfiguriert, dass sie Benutzerzertifikate der Teleport-CA akzeptiert, gehört das Thema Passwort hier praktisch der Vergangenheit an – worüber sich im Zweifelsfall auch die Compliance-Beauftragten freuen.

Fazit

Teleport entpuppt sich als Multitalent für das Herstellen und Verwalten von Verbindungen zwischen Clients und ihren Server-Diensten. Die konsequente Fokussierung auf X.509-Zertifikate bedeutet nicht nur das Ende von Passwörtern, sondern macht so, wie sie in Teleport implementiert ist, auch Spaß. Von der Komplexität einer CA bleiben Admin und Anwender weitgehend abgeschottet, diesen Teil wickelt Teleport fast komplett autark ab – zumindest nach dem anfänglichen Setup. Obendrein überzeugen die Features in Teleport, die Zusatzfunktionalität bieten, wie die Integration in eBPF mit einigen Beispielanwendungen beispielsweise für KRSI.

Wer also einen Bretterverschlag aus SSH, chaotischen Jumphosts und mittelgarer Sicherheit durch eine vernünftige Lösung ersetzen will, der liegt bei Teleport richtig. Das gilt umso mehr als die Lösung sich auch mit einer Vielzahl externer Authentifizierungsoptionen nutzen lässt. Auf Wunsch kann der Anwender in Teleport-Setups sogar den eigenen Verzeichnisdienst einsparen. (jcb/jlu)