Kubelet Authentication & Authorization

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

• Überprüfe die Abonnementpläne!

• Tritt der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folge uns auf Twitter 🐦 @hacktricks_live.

• Teile Hacking-Tricks, indem du PRs zu den HackTricks und HackTricks Cloud GitHub-Repos einreichst.

Kubelet-Authentifizierung

Aus den Docs:

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:

"authentication": {
"anonymous": {
"enabled": true
},

• 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:

"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

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:

"authentication": {
"x509": {
"clientCAFile": "/etc/kubernetes/pki/ca.crt"
}
}

Kubelet Authorization

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:

"authorization": {
"mode": "Webhook",
"webhook": {
"cacheAuthorizedTTL": "5m0s",
"cacheUnauthorizedTTL": "30s"
}
},

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 (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:

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:

curl -k --header "Authorization: Bearer ${TOKEN}" 'https://172.31.28.172:10250/pods'
Forbidden (user=system:node:ip-172-31-28-172.ec2.internal, verb=get, resource=nodes, subresource=proxy)

• 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)

References

• https://kubernetes.io/docs/reference/access-authn-authz/kubelet-authn-authz/

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.