In diesem Blogpost werde ich erklären, warum und wie ich Teleport einsetze und wieso ihr es euch auch überlegen solltet.
Um das ‘warum’ zu erkären, sollte ich erst erklären was genau Teleport ist und wofür es gedacht ist.
Teleport ist dafür gedacht, ähnlich einer SSH Bastion als zentrale, oder dezentrale Zugangsstelle zu Diensten in einem abgeschotteten Netzwerk zu dienen.
Hierfür kann es für SSH, Webapplikationen, Kubernetes und Datenbanken(MongoDB, Postgresql) als Bastion dienen.
Zu den Funktionen von Teleport gehört ein sehr ausgefeiltes Rollenkonzept, sowie die Möglichkeit eines sehr detaillierten Auditsystems, um alle Zugriffe nachvollziehen zu können.
Warum wird Teleport eingesetzt
Wie etwas weiter oben schon angerissen bietet Teleport deutlich modernere und einfachere Methoden als Bastion zu dienen und das nicht nur für SSH, sondern auch für andere Anwendungszwecke.
Zum Zeitpunkt dieses Artikels verwende ich Teleport hauptsächlich um meine privaten VMs zu verwalten, sowie bei einem Kunden, der einen sehr hohen Schutzbedarf hat.
Gerade das ausgefeilte Auditsystem, welches bei Bedarf über BPF sogar die Systemcalls aufzeichnen kann, sowie das Teilen von SSH Sessions mit mehreren Leuten sind unheimlich hilfreich im Enterpriseumfeld um schnell reagieren zu können, wenn man etwas nachverfolgen oder debuggen muss.
Teleport Setup
Das Einrichten von Teleport ist in seiner Standardkonfiguration sehr trivial, die Setup Dokumentation ist sehr gut verständlich und lässt sich gut nachverfolgen.
Da ich bereits eine ältere SSH Bastion hatte, habe ich Teleport auf der gleichen VM installiert.
Meine Konfiguration sieht wie folgend aus:
1
2teleport:
3 data_dir: /var/lib/teleport
4 log:
5 output: stderr
6 severity: INFO
7auth_service:
8 enabled: "yes"
9 authentication:
10 type: local
11 second_factor: off
12 tokens:
13 - "proxy,node,db,app:******************"
14 cluster_name: "astosch.de"
15 listen_addr: 0.0.0.0:3025
16ssh_service:
17 enabled: "yes"
18 labels:
19 env: hosted
20 commands:
21 - name: hostname
22 command: [hostname]
23 period: 1m0s
24 - name: arch
25 command: [uname, -p]
26 period: 1h0m0s
27
28proxy_service:
29 enabled: "yes"
30 listen_addr: 0.0.0.0:3023
31 https_keypairs: []
32 acme: {}
33 public_addr: "<public_url>"
Wenn man die Dokumentation liest, sieht man hier direkt einige Unterschiede.
Zum einen habe ich momentan noch die Zweifaktorauthentifizierung deaktiviert und ein statisches Token gesetzt, da es mit Ansible so etwas einfacher ist, die anderen Nodes aufzusetzen.
Diese benötigen nämlich in ihrer Konfiguration das entsprechende Token, um sich dem Cluster anzuschliessen.
1
2teleport:
3 auth_token: **************
4 log:
5 output: stderr
6 severity: INFO
7 format:
8 output: text
9 ca_pin: ""
10 auth_servers:
11 - <authservice.public_addr>
12auth_service:
13 enabled: "no"
14ssh_service:
15 enabled: "yes"
16 labels:
17 env: hosted
18 commands:
19 - name: hostname
20 command: [hostname]
21 period: 1m0s
22 - name: arch
23 command: [uname, -p]
24 period: 1h0m0s
Wenn man alles richtig gemacht hat, kann man sich nun auf der neuen Bastion einloggen und bekommt etwas, dass so ähnlich aussieht:
Schon ist es “fertig”.
Teleport kann als Bastion benutzt werden.
Im nächsten Blogpost werde ich darauf eingehen, wie das Auditsystem von Teleport funktioniert und wie man Session mit mehreren Benutzern teilen kann.