Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Standardmäßig werden Anfragen an den HTTPS-Endpunkt des Kubelets, die nicht von anderen konfigurierten Authentifizierungsmethoden abgelehnt werden, als anonyme Anfragen behandelt und erhalten einen Benutzernamen von system:anonymous und eine Gruppe von system:unauthenticated.
Die 3 Authentifizierungsmethoden sind:
Anonym (Standard): Verwende die Einstellung, indem du den Parameter --anonymous-auth=true oder die Konfiguration:
Webhook: Dies wird die API-Bearer-Token von kubectl als Autorisierung aktivieren (jedes gültige Token wird gültig sein). Erlauben Sie es mit:
Stellen Sie sicher, dass die API-Gruppe authentication.k8s.io/v1beta1 im API-Server aktiviert ist
Starten Sie den Kubelet mit den --authentication-token-webhook und --kubeconfig Flags oder verwenden Sie die folgende Einstellung:
Der Kubelet ruft die TokenReview API auf dem konfigurierten API-Server auf, um Benutzerinformationen aus Bearer-Token zu bestimmen.
X509-Clientzertifikate: Ermöglichen die Authentifizierung über X509-Clientzertifikate.
Siehe die Dokumentation zur Authentifizierung des Apiservers für weitere Details.
Starten Sie den Kubelet mit dem --client-ca-file-Flag und geben Sie ein CA-Bündel an, um Clientzertifikate zu überprüfen. Oder mit der Konfiguration:
Jede Anfrage, die erfolgreich authentifiziert wird (einschließlich einer anonymen Anfrage), wird dann autorisiert. Der Standard-Autorisierungsmodus ist AlwaysAllow, der alle Anfragen erlaubt.
Der andere mögliche Wert ist jedoch webhook (was Sie hauptsächlich dort finden werden). Dieser Modus prüft die Berechtigungen des authentifizierten Benutzers, um eine Aktion zu erlauben oder abzulehnen.
Beachten Sie, dass selbst wenn die anonyme Authentifizierung aktiviert ist, der anonyme Zugriff möglicherweise keine Berechtigungen hat, um eine Aktion auszuführen.
Die Autorisierung über Webhook kann mit dem Parameter --authorization-mode=Webhook oder über die Konfigurationsdatei konfiguriert werden:
Der Kubelet ruft die SubjectAccessReview API auf dem konfigurierten API-Server auf, um festzustellen, ob jede Anfrage autorisierte ist.
Der Kubelet autorisiert API-Anfragen mit demselben Anfrageattribut Ansatz wie der Apiserver:
Aktion
| HTTP-Verb | Anfrage-Verb |
|---|---|
POST | erstellen |
GET, HEAD | abrufen (für einzelne Ressourcen), auflisten (für Sammlungen, einschließlich des vollständigen Objektinhalts), beobachten (zum Beobachten einer einzelnen Ressource oder Sammlung von Ressourcen) |
PUT | aktualisieren |
PATCH | patchen |
DELETE | löschen (für einzelne Ressourcen), sammlunglöschen (für Sammlungen) |
Die Ressource, die mit der Kubelet-API kommuniziert, ist immer nodes und subresource wird aus dem Pfad der eingehenden Anfrage bestimmt:
| Kubelet API | Ressource | Subressource |
|---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
alle anderen | nodes | proxy |
Zum Beispiel versuchte die folgende Anfrage, auf die Pods-Informationen des Kubelet ohne Berechtigung zuzugreifen:
Wir haben ein Verboten, also hat die Anfrage die Authentifizierungsprüfung bestanden. Andernfalls hätten wir nur eine Nicht autorisiert-Nachricht erhalten.
Wir können den Benutzernamen sehen (in diesem Fall aus dem Token)
Überprüfen Sie, wie die Ressource Knoten und die Unterressource Proxy war (was mit den vorherigen Informationen Sinn macht)
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
