Kubelet Authentication & Authorization

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks im PDF-Format herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merch

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

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

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud Github-Repositories einreichen.

Kubelet-Authentifizierung

Aus den Dokumenten:

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): Verwenden Sie die Einstellung --anonymous-auth=true oder die Konfiguration:

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

• Webhook: Dies aktiviert die kubectl API Bearer Tokens als Autorisierung (jedes gültige Token wird akzeptiert). Erlauben Sie es mit:

• Stellen Sie sicher, dass die authentication.k8s.io/v1beta1 API-Gruppe 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-Client-Zertifikate: Ermöglichen die Authentifizierung über X509-Client-Zertifikate

• siehe die Dokumentation zur API-Server-Authentifizierung für weitere Details

• Starten Sie den kubelet mit der --client-ca-file-Flag, indem Sie ein CA-Bundle bereitstellen, um Client-Zertifikate zu überprüfen. Oder mit der Konfiguration:

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

Kubelet Autorisierung

Jede Anfrage, die erfolgreich authentifiziert wurde (einschließlich einer anonymen Anfrage), wird dann autorisiert. Der Standard-Autorisierungsmodus ist AlwaysAllow, der alle Anfragen zulässt.

Die andere mögliche Option ist jedoch webhook (was Sie hauptsächlich dort finden werden). In diesem Modus werden die Berechtigungen des authentifizierten Benutzers überprüft, 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 zu bestimmen, ob jede Anfrage autorisiert ist.

Der kubelet autorisiert API-Anfragen unter Verwendung des gleichen Anfrageattribut-Ansatzes wie der apiserver:

• Aktion

HTTP-Verb	Anfrageverb
POST	erstellen
GET, HEAD	abrufen (für einzelne Ressourcen), auflisten (für Sammlungen, einschließlich vollständigem Objektinhalt), beobachten (für das Beobachten einer einzelnen Ressource oder einer Sammlung von Ressourcen)
PUT	aktualisieren
PATCH	patchen
DELETE	löschen (für einzelne Ressourcen), deletecollection (für Sammlungen)

• Die Ressource, die mit der Kubelet-API spricht, ist immer nodes und die Unterressource wird aus dem Pfad der eingehenden Anfrage bestimmt:

Kubelet-API	Ressource	Unterressource
/stats/*	nodes	stats
/metrics/*	nodes	metrics
/logs/*	nodes	log
/spec/*	nodes	spec
alle anderen	nodes	proxy

Beispielhaft versuchte die folgende Anfrage, ohne Berechtigung auf die Pod-Informationen des kubelet 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, daher hat die Anfrage die Authentifizierungsprüfung bestanden. Andernfalls hätten wir nur eine Unbefugt-Nachricht erhalten.

• Wir können den Benutzernamen sehen (in diesem Fall vom Token)

• Überprüfen Sie, wie die Ressource nodes und die Unterressource proxy war (was mit den vorherigen Informationen Sinn macht)

Referenzen

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

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks beworben sehen möchten oder HackTricks im PDF-Format herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!

• Holen Sie sich das offizielle PEASS & HackTricks-Merch

• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

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

• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositorys einreichen.