<p>teleport-kube-agent registriert sich nicht erneut, nachdem der Proxy neu erstellt wurde</p>

Erstellt am 25. Feb. 2021  ·  6Kommentare  ·  Quelle: gravitational/teleport

Beschreibung

Was ist passiert :

Wir haben eine automatisierte Bereitstellung des Teleportservers hinter einer ASG. Wenn wir eine Konfigurationsänderung vornehmen, wird eine neue Instanz gestartet.
Wir haben festgestellt, dass wir bei einem tsh kube ls keinen zuvor bereitgestellten teleport-kube-agent sehen. Nur neu bereitgestellte kube-agents werden angezeigt, wenn ihr Pod gestartet wird.

Was Sie erwartet haben, zu passieren :
Ich würde erwarten, dass sich alle laufenden kube-Agents irgendwann selbst registrieren.

Reproduktionsschritte

Beschreiben Sie so minimal und genau wie möglich Schritt für Schritt, wie Sie das Problem reproduzieren können.

  1. Stellen Sie einen eigenständigen Teleport-Server mit aktiviertem Kubernetes-Proxy bereit
  2. Stellen Sie einen EKS-Cluster mit teleport-kube-agent bereit, der auf den Proxy zeigt
  3. Erstellen Sie einen neuen eigenständigen Teleportserver mit demselben DNS-Namen
  4. tsh kube ls zeigt den Cluster nicht an
  5. kubectl -n TELEPORT_NS delete po -l app.kubernetes.io/name=teleport-kube-agent
  6. tsh kube ls zeigt den Cluster

Serverdetails

  • Teleport-Version ( teleport version ausführen): Teleport v5.1.2 git:v5.1.2-0-g822d10b44 go1.15.5
  • Server OS (zB von /etc/os-release ): Ubuntu 20.04.2 LTS
  • Wo läuft Teleport? (z. B. AWS, GCP, dedizierte Hardware): AWS
  • Weitere Details:

Kundendetails

  • Tsh-Version ( tsh version ): Teleport v5.1.2 git: go1.15.7
  • Computerbetriebssystem (zB Linux, macOS, Windows): macOS
  • Browserversion (für UI-bezogene Probleme):
  • Installiert über (zB apt, yum, brew, Website-Download): Website
  • Weitere Details:

Debug-Protokolle

Fügen Sie ggf. Debug-Logs hinzu oder fügen Sie sie bei. Verschleiern Sie sensible Informationen!

  • Starte Teleport mit --debug Flag ( teleport --debug )
  • Führen Sie tsh mit dem Flag --debug aus ( tsh --debug )

teleport-kube-agent protokolliert, nachdem der Server neu erstellt wurde

[KUBERNETES]   Kubernetes service 5.1.2:v5.1.2-0-g822d10b44 is starting via proxy reverse tunnel.
E0223 23:00:09.984802       6 v2.go:105] EOF
E0223 23:00:22.676411       6 v2.go:105] EOF
E0223 23:00:26.243752       6 v2.go:105] EOF
E0223 23:00:36.236028       6 v2.go:105] EOF
E0223 23:00:39.879072       6 v2.go:105] EOF
E0223 23:00:40.020085       6 v2.go:105] EOF
ERRO [KUBERNETE] Error copying upstream response Body: context canceled forward/fwd.go:203
2021/02/23 23:12:29 http: superfluous response.WriteHeader call from github.com/gravitational/teleport/lib/kube/proxy.(*responseStatusRecorder).WriteHeader (forwarder.go:1643)
E0223 23:13:49.662650       6 v2.go:105] EOF
E0223 23:13:58.250475       6 v2.go:105] EOF
E0223 23:14:01.766591       6 v2.go:105] EOF
E0223 23:14:10.603254       6 v2.go:105] EOF
E0223 23:14:12.390978       6 v2.go:105] EOF
E0223 23:14:12.411914       6 v2.go:105] EOF
ERRO [KUBERNETE] Error copying upstream response Body: context canceled forward/fwd.go:203
2021/02/23 23:20:05 http: superfluous response.WriteHeader call from github.com/gravitational/teleport/lib/kube/proxy.(*responseStatusRecorder).WriteHeader (forwarder.go:1643)
ERRO [KUBERNETE] Error copying upstream response Body: context canceled forward/fwd.go:203
2021/02/23 23:20:27 http: superfluous response.WriteHeader call from github.com/gravitational/teleport/lib/kube/proxy.(*responseStatusRecorder).WriteHeader (forwarder.go:1643)
ERRO [KUBERNETE] Error copying upstream response Body: context canceled forward/fwd.go:203
2021/02/23 23:22:39 http: superfluous response.WriteHeader call from github.com/gravitational/teleport/lib/kube/proxy.(*responseStatusRecorder).WriteHeader (forwarder.go:1643)

teleport-kube-agent logs, nachdem der Pod neu erstellt wurde

[KUBERNETES]   Kubernetes service 5.1.2:v5.1.2-0-g822d10b44 is starting via proxy reverse tunnel.

Welche Plattform(en)

  • [x] Teleport Open Source
  • [ ] Teleport-Wolke
  • [ ] Teleportunternehmen
  • [ ] Andere

Welche Komponente(n)

  • [ ] Serverzugriff
  • [x] Kubernetes-Zugriff
  • [ ] Anwendungszugriff
  • [ ] Datenbankzugriff
  • [ ] CLI-Clients
  • [ ] Web-Clients
  • [ ] Andere
bug
Quelle
picture fraenkel

Alle 6 Kommentare

Ist Ihr Proxy mit demselben Teleport-Authentifizierungsserver wie zuvor verbunden? Wenn dies der Fall ist, sollten sich die kube-Agenten neu registrieren und erscheinen, sobald sie feststellen, dass ihre Verbindung zum Proxy unterbrochen wurde.

Wenn sich der Authentifizierungsserver ändert, versuchen die Kube-Agenten weiterhin, eine Verbindung mit zwischengespeicherten Zertifikaten für den alten Authentifizierungsserver herzustellen - dies erfordert manuelle Eingriffe (dh Löschen von /var/lib/teleport im Pod oder Neustarten).

webvictim picture webvictim am 25. Feb. 2021

Es ist ein All-in-One, also auch ein neuer Authentifizierungsserver.
Ich habe ein statisches Kube-Token, das ich als authToken für den Teleport-Kube-Agent verwende.
Willst du damit sagen, dass ich mehr statische Token brauche? Ich sehe Verweise in den Dokumenten, aber keine davon sind im Teleport Kubernetes Access angegeben.

Die Dokumente erwähnen Token für Knoten und Proxy und dann einen separaten für die Authentifizierung. Aber es gibt keine klare Erklärung, wie sie auf der Agentenseite verwendet werden.

fraenkel picture fraenkel am 25. Feb. 2021

Wenn Sie einen Agenten mit einem statischen Token einem Teleport-Cluster beitreten, generiert die Zertifizierungsstelle des Clusters einen Schlüssel und signiert ein Zertifikat, das der Agent dann auf der Festplatte zwischenspeichert und für jede zukünftige Authentifizierung mit dem Cluster (über gegenseitiges TLS) verwendet.

Ohne persistenten Speicher generiert beim Starten eines neuen Teleport-Authentifizierungsservers eine neue Zertifizierungsstelle, sodass alle alten Zertifikate ungültig werden. Daher kann sich ein aktiver Agent, der zuvor einem anderen Teleport-Cluster beigetreten ist, nicht mit dem neuen authentifizieren, selbst wenn Sie dieselbe statische Token-Zeichenfolge in der Konfiguration des Clusters definieren. Dies ist in gewisser Weise beabsichtigt, um ein Szenario zu verhindern, in dem ein Teleport-Cluster von einem Angreifer übernommen werden könnte, der dann die Kontrolle über alle vorhandenen Knoten erlangen würde, wenn sie wieder beitreten.

Die einzige Möglichkeit, einen laufenden Agenten mit zwischengespeicherten Zertifikaten zu zwingen, einem neuen Cluster wieder beizutreten, besteht darin, zwischengespeicherte Zertifikate auf dem Agenten zu löschen (der einfachste Weg besteht darin, den Inhalt von /var/lib/teleport zu entfernen) und dann den Teleport-Prozess neu zu starten. Das Beenden des Pods und der Neustart durch Kubernetes funktioniert auch, da der Speicher des Pods kurzlebig ist, sodass die Zertifikate gelöscht werden, wenn der Pod beendet wird.

Eine Möglichkeit, dies zu vermeiden, besteht darin, sicherzustellen, dass Ihr Teleport-Authentifizierungsserver eine Art persistenten Speicher konfiguriert hat, und dann kill -HUP $(pidof teleport) auf dem Authentifizierungsserver, wenn sich die Konfiguration ändert. Dadurch wird ein neuer Teleport-Prozess mit der geänderten Konfiguration abgespalten und der alte Prozess heruntergefahren, wenn keine aktiven Benutzerverbindungen zum alten Prozess bestehen. Da dies die gleiche Zertifizierungsstelle behalten würde, würden Ihre Agenten dann problemlos wieder beitreten.

(bezogen auf #2838)

webvictim picture webvictim am 25. Feb. 2021

Es ist ein bisschen ein Henne-Ei-Problem. Wir brauchen Teleport, um auf den k8s-Cluster zuzugreifen. Aber das besagt, dass ich eingehenden Zugriff auf alle meine Netzwerke haben muss und außerdem eine kubeconfig habe, damit ich die Pods springen kann.

fraenkel picture fraenkel am 25. Feb. 2021

Ich kann sehen, was du sagst. Die Empfehlung hier wäre definitiv, dass Ihr zentraler Teleport-Cluster (mit dem sich die Agenten verbinden) viel statischer / persistenter / hochverfügbarer sein sollte als die Agenten selbst, damit Sie den Zugriff behalten können.

webvictim picture webvictim am 25. Feb. 2021
👍1

Ich sehe, dass ich entweder dynamodb, etcd verwende oder ebs auf magische Weise mit ASGs zusammenarbeite, um eine zustandslose Authentifizierungsinstanz zu ermöglichen.

fraenkel picture fraenkel am 26. Feb. 2021
👍1
War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

Kellel picture Kellel  ·  3Kommentare
klizhentas picture klizhentas  ·  5Kommentare
cnelson picture cnelson  ·  5Kommentare
tomberek picture tomberek  ·  5Kommentare
webvictim picture webvictim  ·  3Kommentare