Kubelet Authentication & Authorization
Last updated
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, um ein CA-Bundle bereitzustellen, 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 wird die Berechtigungen des authentifizierten Benutzers überprüfen, 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 mit:
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
POST
erstellen
GET, HEAD
abrufen (für einzelne Ressourcen), auflisten (für Sammlungen, einschließlich des vollständigen Objektinhalts), beobachten (für das Beobachten einer einzelnen Ressource oder Sammlung von Ressourcen)
PUT
aktualisieren
PATCH
patch
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:
/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 Forbidden erhalten, also hat die Anfrage die Authentifizierungsprüfung bestanden. Andernfalls hätten wir nur eine Unauthorised-Nachricht erhalten.
Wir können den Benutzernamen sehen (in diesem Fall aus dem Token)
Überprüfen Sie, wie die Ressource nodes und die Subressource proxy war (was mit den vorherigen Informationen Sinn macht)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
