Kubelet-Authentifizierung & -Autorisierung

Tip

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

Unterstütze HackTricks

Kubelet-Authentifizierung

Aus der Dokumentation:

Standardmäßig werden Anfragen an den HTTPS-Endpunkt des kubelet, die nicht von anderen konfigurierten Authentifizierungsmethoden zurückgewiesen werden, als anonyme Anfragen behandelt und erhalten einen Benutzernamen von system:anonymous und eine Gruppe von system:unauthenticated.

Die 3 Authentifizierungsmethoden sind:

  • Anonymous (Standard): Setzen Sie den Parameter --anonymous-auth=true oder konfigurieren Sie dies in der Konfiguration:
"authentication": {
"anonymous": {
"enabled": true
},
  • Webhook: Dadurch werden die kubectl API bearer tokens als Autorisierung aktiviert (jeder gültige Token wird akzeptiert). Aktiviere es mit:
  • Stelle sicher, dass die authentication.k8s.io/v1beta1 API-Gruppe im API server aktiviert ist
  • Starte kubelet mit den --authentication-token-webhook und --kubeconfig Flags oder verwende die folgende Einstellung:
"authentication": {
"webhook": {
"cacheTTL": "2m0s",
"enabled": true
},

Note

kubelet ruft die TokenReview API auf dem konfigurierten API-Server auf, um Benutzerinformationen aus bearer tokens zu ermitteln

  • X509 client certificates: Ermöglichen die Authentifizierung über X509 client certs
  • siehe die apiserver authentication documentation für weitere Details
  • Starte kubelet mit dem --client-ca-file Flag und übergib ein CA-Bundle zur Verifizierung der Client-Zertifikate. 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 anschließend autorisiert. Der Standard-Autorisierungsmodus ist AlwaysAllow, der alle Anfragen zulässt.

Der andere mögliche Wert ist jedoch webhook (was Sie meist dort antreffen werden). Dieser Modus prüft die Berechtigungen des authentifizierten Benutzers, um eine Aktion zu erlauben oder zu verweigern.

Warning

Beachten Sie, dass selbst wenn die anonyme Authentifizierung aktiviert ist, der anonyme Zugriff möglicherweise keine Berechtigungen hat, irgendeine Aktion auszuführen.

Die Autorisierung über webhook kann mit dem Parameter --authorization-mode=Webhook oder über die Konfigurationsdatei mit:

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

Der kubelet ruft die SubjectAccessReview API auf dem konfigurierten apiserver auf, um zu bestimmen, ob jede Anfrage autorisiert ist.

Der kubelet authorisiert API-Anfragen mithilfe des gleichen request attributes Ansatzes wie der apiserver:

  • Action
HTTP verbrequest verb
POSTcreate
GET, HEADget (for individual resources), list (for collections, including full object content), watch (for watching an individual resource or collection of resources)
PUTupdate
PATCHpatch
DELETEdelete (for individual resources), deletecollection (for collections)
  • Die resource, die mit der Kubelet api kommuniziert, ist immer nodes und die subresource wird aus dem Pfad der eingehenden Anfrage bestimmt:
Kubelet APIresourcesubresource
/stats/*nodesstats
/metrics/*nodesmetrics
/logs/*nodeslog
/spec/*nodesspec
all othersnodesproxy

Note

WebSocket-based /exec, /run, /attach, and /portforward fall into the default proxy subresource and are authorized using the initial HTTP GET handshake. A principal with only nodes/proxy GET can still exec containers if it connects directly to https://<node_ip>:10250 over WebSockets. See the nodes/proxy GET -> Kubelet /exec verb confusion abuse for details.

Zum Beispiel versuchte die folgende Anfrage, ohne Berechtigung auf die pods-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 Forbidden erhalten, daher hat die Anfrage die passed the Authentication check bestanden. Wenn nicht, hätten wir nur eine Unauthorised-Meldung erhalten.
  • Wir können den username sehen (in diesem Fall aus dem token)
  • Prüfe, dass die resource nodes und die subresource proxy waren (was im Einklang mit den vorherigen Informationen steht)

Referenzen

Tip

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

Unterstütze HackTricks