Kubelet Authentication & Authorization
Kubelet Authentifizierung
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 Authentifizierung Methoden sind:
Anonym (Standard): Verwenden Sie die Einstellung
--anonymous-auth=true
oder die Konfiguration:
Webhook: Dies wird die Verwendung von kubectl API-Bärentoken als Autorisierung aktivieren (jeder gültige Token wird akzeptiert). Erlauben Sie es mit:
Stellen Sie sicher, dass die
authentication.k8s.io/v1beta1
API-Gruppe im API-Server aktiviert istStarten Sie den Kubelet mit den Flags
--authentication-token-webhook
und--kubeconfig
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-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:
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.
Der andere mögliche Wert 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:
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 |
Zum Beispiel versuchte die folgende Anfrage, ohne Berechtigung auf die Pod-Informationen des kubelet zuzugreifen:
Wir haben ein Verboten erhalten, also 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
Last updated