Kubelet-Authentifizierung & Autorisierung

Reading time: 5 minutes

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 Authentifizierung Methoden sind:

• Anonym (Standard): Verwenden Sie die Einstellung des Parameters --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
},

• X509-Clientzertifikate: Ermöglichen die Authentifizierung über X509-Clientzertifikate
• siehe die apiserver authentication documentation 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-Authentifizierung

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 prüft die Berechtigungen des authentifizierten Benutzers, um eine Aktion zu erlauben oder abzulehnen.

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

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

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/