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

Standardmäßig werden Anfragen an den HTTPS-Endpunkt des Kubelets, die von anderen konfigurierten Authentifizierungsmethoden nicht 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 apiserver-Authentifizierungsdokumentation 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 wurde (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:

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

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 Verboten erhalten, 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)

Referenzen

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

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.

• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.