3.2.2 - Stellen Sie sicher, dass das Argument --authorization-mode nicht auf AlwaysAllow gesetzt ist (Automatisiert)

Ansichten:

Profilanwendbarkeit: Stufe 1

Nicht alle Anfragen zulassen. Explizite Autorisierung aktivieren.

Kubelets können so konfiguriert werden, dass sie alle authentifizierten Anfragen (auch anonyme) zulassen, ohne dass explizite Autorisierungsprüfungen vom Apiserver erforderlich sind. Sie sollten dieses Verhalten einschränken und nur explizit autorisierte Anfragen zulassen.

Hinweis

Siehe die GKE-Dokumentation für den Standardwert.

Auswirkung

Siehe die GKE-Dokumentation für den Standardwert.

Prüfung

Prüfmethode 1:

Kubelets können Konfigurationen aus einer Konfigurationsdatei und in einigen Fällen aus Befehlszeilenargumenten akzeptieren. Es ist wichtig zu beachten, dass Parameter, die als Befehlszeilenargumente bereitgestellt werden, ihre entsprechenden Parameter in der Konfigurationsdatei überschreiben (siehe --config Details in der Kubelet CLI-Referenz für Weitere Informationen, wo Sie auch herausfinden können, welche Konfigurationsparameter als Befehlszeilenargument bereitgestellt werden können). Vor diesem Hintergrund ist es wichtig, sowohl das Vorhandensein von Befehlszeilenargumenten als auch von Einträgen in der Konfigurationsdatei zu überprüfen, wenn die Kubelet-Konfiguration geprüft wird.

SSH zu jedem Knoten und führen Sie den folgenden Befehl aus, um den Kubelet-Prozess zu finden:
```
ps -ef | grep kubelet
```
Die Ausgabe des obigen Befehls liefert Details zum aktiven Kubelet-Prozess, aus denen wir die dem Prozess übergebenen Befehlszeilenargumente sehen können. Beachten Sie auch den Speicherort der Konfigurationsdatei, die mit dem Argument --config bereitgestellt wird, da diese zur Überprüfung der Konfiguration benötigt wird.
Die Datei kann mit einem Befehl wie more oder less angezeigt werden:
```
sudo less /path/to/kubelet-config.json
```
Überprüfen Sie, ob die Webhook-Authentifizierung aktiviert ist. Dies kann als Befehlszeilenargument für den Kubelet-Dienst mit --authentication-token-webhook oder in der Kubelet-Konfigurationsdatei mit "authentication": { "webhook": { "enabled": true } } konfiguriert werden.
Überprüfen Sie, ob der Autorisierungsmodus auf WebHook eingestellt ist. Dies kann als Befehlszeilenargument für den Kubelet-Dienst mit --authorization-mode=Webhook oder in der Konfigurationsdatei mit "authorization": { "mode": "Webhook } festgelegt werden.

Prüfmethode 2:

Es ist auch möglich, die laufende Konfiguration eines Kubelet über den /configz-Endpunkt der Kubernetes-API zu überprüfen. Verwenden Sie kubectl, um Ihre Anfragen an die API zu proxyen.

Entdecken Sie alle Knoten in Ihrem Cluster, indem Sie den folgenden Befehl ausführen:
```
kubectl get nodes
```
Initialisieren Sie einen Proxy mit kubectl auf einem lokalen Port Ihrer Wahl, zum Beispiel:
```
kubectl proxy --port=8080
```
Während dies läuft, führen Sie in einem separaten Terminal den folgenden Befehl für jeden Knoten aus:
```
export NODE_NAME=my-node-name 
curl http://localhost:8080/api/v1/nodes/${NODE_NAME}/proxy/configz
```
Der Curl-Befehl gibt die API-Antwort zurück, die eine JSON-formatierte Zeichenkette darstellt, die die Kubelet-Konfiguration repräsentiert.
Überprüfen Sie, ob die Webhook-Authentifizierung aktiviert ist, indem Sie sicherstellen, dass "authentication": { "webhook": { "enabled": true } } in der API-Antwort enthalten ist.
Überprüfen Sie, ob der Autorisierungsmodus im API-Antwort mit WebHook auf "authorization": { "mode": "Webhook } eingestellt ist.

Wiederherstellung

Bereinigungsmethode 1:

Wenn Sie über die Kubelet-Konfigurationsdatei konfigurieren, lokalisieren Sie zuerst die Datei:

SSH zu jedem Knoten und führen Sie den folgenden Befehl aus, um den Kubelet-Prozess zu finden:
```
ps -ef | grep kubelet
```
Die Ausgabe des obigen Befehls liefert Details des aktiven Kubelet-Prozesses, aus denen wir den Speicherort der Konfigurationsdatei sehen können, die dem Kubelet-Dienst mit dem Argument --config bereitgestellt wird.
Die Datei kann mit einem Befehl wie more oder less angezeigt werden:
```
sudo less /path/to/kubelet-config.json
```
Aktivieren Sie die Webhook-Authentifizierung, indem Sie den folgenden Parameter festlegen:
```
"authentication": { "anonymous": { "enabled": false } }
```
Als Nächstes setzen Sie den Autorisierungsmodus auf Webhook, indem Sie den folgenden Parameter festlegen:
```
"authorization": { "mode": "Webhook }
```
Feinere Details der Authentifizierungs- und Autorisierungsfelder finden Sie in der Kubelet-Konfigurationsdokumentation.

Sanierungsmethode 2:

Wenn ausführbare Argumente verwendet werden, bearbeiten Sie die Kubelet-Dienstdatei auf jedem Worker-Knoten und stellen Sie sicher, dass die untenstehenden Parameter Teil der KUBELET_ARGS-Variablenzeichenfolge sind.
Für Systeme, die systemd verwenden, wie die Amazon EKS Optimized Amazon Linux oder Bottlerocket AMIs, kann diese Datei unter /etc/systemd/system/kubelet.service.d/10-kubelet-args.conf gefunden werden.
Andernfalls müssen Sie möglicherweise die Dokumentation für Ihr gewähltes Betriebssystem nachschlagen, um festzustellen, welcher Dienstmanager konfiguriert ist:
```
--authentication-token-webhook
--authorization-mode=Webhook
```

Für beide Abhilfemaßnahmen:

Basierend auf Ihrem System starten Sie den kubelet-Dienst neu und überprüfen Sie den Dienststatus. Das folgende Beispiel gilt für Betriebssysteme, die systemd verwenden, wie die Amazon EKS Optimised Amazon Linux oder Bottlerocket AMIs, und ruft den systemctl-Befehl auf. Wenn systemctl nicht verfügbar ist, müssen Sie die Dokumentation für Ihr gewähltes Betriebssystem konsultieren, um festzustellen, welcher Dienstmanager konfiguriert ist:

systemctl daemon-reload 
systemctl restart kubelet.service 
systemctl status kubelet -l