Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

CIS 1.7 Selbstbewertungshandbuch

Übersicht

Dieses Dokument ist ein Begleitdokument zum K3s-Sicherheits-Härtungsleitfaden. Der Härtungsleitfaden bietet verbindliche Anleitungen zur Härtung einer Produktionsinstallation von K3s, und dieser Benchmark-Leitfaden soll Ihnen helfen, das Sicherheitsniveau des gehärteten Clusters im Vergleich zu jeder Kontrolle im CIS Kubernetes Benchmark zu bewerten. Er ist für K3s-Betreiber, Sicherheitsteams, Prüfer und Entscheidungsträger gedacht.

Dieser Leitfaden ist spezifisch für die v1.25 Release-Linie von K3s und die v1.7.1 Version des CIS Kubernetes Benchmarks.

Für weitere Informationen zu jeder Kontrolle, einschließlich detaillierter Beschreibungen und Maßnahmen für fehlgeschlagene Tests, können Sie auf den entsprechenden Abschnitt des CIS Kubernetes Benchmarks v1.7.1 verweisen. Sie können den Benchmark herunterladen, nachdem Sie ein kostenloses Konto erstellt haben, im Center for Internet Security (CIS).

Testmethodik für Kontrollen

Jede Kontrolle im CIS Kubernetes Benchmark wurde gegen ein K3s-Cluster bewertet, das gemäß dem begleitenden Härtungsleitfaden konfiguriert wurde.

Wo die Kontrollprüfungen vom ursprünglichen CIS-Benchmark abweichen, werden die spezifischen Prüfbefehle für K3s zum Testen bereitgestellt.

Dies sind die möglichen Ergebnisse für jede Kontrolle:

  • Bestanden - Das getestete K3s-Cluster hat die im Benchmark skizzierte Prüfung bestanden.

  • Nicht anwendbar - Die Kontrolle ist für K3s nicht anwendbar, aufgrund der Art und Weise, wie sie konzipiert ist zu arbeiten. Der Abschnitt zur Behebung wird erklären, warum dies so ist.

  • Warnung - Die Kontrolle ist manuell im CIS-Benchmark und hängt vom Anwendungsfall des Clusters oder einem anderen Faktor ab, der vom Clusterbetreiber bestimmt werden muss. Diese Kontrollen wurden bewertet, um sicherzustellen, dass K3s deren Implementierung nicht verhindert, aber es wurde keine weitere Konfiguration oder Prüfung des getesteten Clusters durchgeführt.

Dieser Leitfaden geht davon aus, dass K3s als Systemd-Einheit ausgeführt wird. Ihre Installation kann variieren und erfordert, dass Sie die „audit“-Befehle an Ihr Szenario anpassen.

Nur scored Tests, auch bekannt als automated Tests, werden in diesem Leitfaden behandelt.

1.1 Konfigurationsdateien für Control-Plane-Knoten

1.1.1 Stellen Sie sicher, dass die Berechtigungen der API-Server-Pod-Spezifikationsdatei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s den API-Server in den K3s-Prozess ein. Es gibt keine API-Server-Pod-Spezifikationsdatei.

1.1.2 Stellen Sie sicher, dass der Eigentümer der API-Server-Pod-Spezifikationsdatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s den API-Server in den K3s-Prozess ein. Es gibt keine API-Server-Pod-Spezifikationsdatei.

1.1.3 Stellen Sie sicher, dass die Berechtigungen der Controller-Manager-Pod-Spezifikationsdatei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s den Controller-Manager in den K3s-Prozess ein. Es gibt keine Controller-Manager-Pod-Spezifikationsdatei.

1.1.4 Stellen Sie sicher, dass der Eigentümer der Controller-Manager-Pod-Spezifikationsdatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s den Controller-Manager in den K3s-Prozess ein. Es gibt keine Controller-Manager-Pod-Spezifikationsdatei.

1.1.5 Stellen Sie sicher, dass die Berechtigungen der Scheduler-Pod-Spezifikationsdatei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s den Scheduler in den K3s-Prozess ein. Es gibt keine Scheduler-Pod-Spezifikationsdatei.

1.1.6 Stellen Sie sicher, dass der Eigentümer der Scheduler-Pod-Spezifikationsdatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s den Scheduler in den K3s-Prozess ein. Es gibt keine Scheduler-Pod-Spezifikationsdatei.

1.1.7 Stellen Sie sicher, dass die Berechtigungen der etcd-Pod-Spezifikationsdatei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s etcd in den K3s-Prozess ein. Es gibt keine etcd-Pod-Spezifikationsdatei.

1.1.8 Stellen Sie sicher, dass der Eigentümer der etcd-Pod-Spezifikationsdatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig bettet K3s etcd in den K3s-Prozess ein. Es gibt keine etcd-Pod-Spezifikationsdatei.

1.1.9 Stellen Sie sicher, dass die Berechtigungen der Container-Netzwerkschnittstellendatei auf 600 oder restriktiver gesetzt sind (Manuell)

Ergebnis: WARN

Behebung: Standardmäßig setzt K3s die CNI-Dateiberechtigungen auf 644. Beachten Sie, dass für viele CNIs eine Sperrdatei mit Berechtigungen 750 erstellt wird. Dies ist zu erwarten und kann ignoriert werden. Wenn Sie Ihre CNI-Konfiguration ändern, stellen Sie sicher, dass die Berechtigungen auf 600 gesetzt sind. Zum Beispiel, chmod 600 /var/lib/cni/networks/<filename>

1.1.10 Stellen Sie sicher, dass der Eigentümer der Container-Netzwerkschnittstellendatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

ps -ef | grep containerd | grep -- --cni-conf-dir | sed 's%.*cni-conf-dir[= ]\([^ ]*\).*%\1%' | xargs -I{} find {} -mindepth 1 | xargs --no-run-if-empty stat -c %U:%G
find /var/lib/cni/networks -type f 2> /dev/null | xargs --no-run-if-empty stat -c %U:%G

Erwartetes Ergebnis: 'root:root' ist vorhanden

Zurückgegebener Wert: 
root:root
root:root
root:root
root:root
root:root
root:root
root:root
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chown root:root <path/to/cni/files>

1.1.11 Stellen Sie sicher, dass die Berechtigungen des etcd-Datenverzeichnisses auf 700 oder restriktiver gesetzt sind (automatisiert)

Ergebnis: PASS

Revision:

if [ "$(journalctl -u k3s | grep -m1 'Managed etcd cluster' | wc -l)" -gt 0 ]; then
  stat -c permissions=%a /var/lib/rancher/k3s/server/db/etcd
else
  echo "permissions=700"
fi

Erwartetes Ergebnis: Die Berechtigungen sind auf 700 gesetzt; es werden 700 oder restriktivere Berechtigungen erwartet.

Zurückgegebener Wert: 
permissions=700
Behebung:

Ermitteln Sie auf dem etcd-Serverknoten das etcd-Datenverzeichnis, das als Argument --data-dir an den Befehl 'ps -ef | grep etcd' übergeben wird. Führen Sie den folgenden Befehl aus (basierend auf dem oben gefundenen etcd-Datenverzeichnis). Zum Beispiel, chmod 700 /var/lib/rancher/k3s/server/db/etcd

1.1.12 Stellen Sie sicher, dass der Eigentümer des etcd-Datenverzeichnisses auf etcd:etcd gesetzt ist (automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Für K3s ist etcd im k3s-Prozess eingebettet. Es gibt keinen separaten etcd-Prozess. Daher wird der Eigentümer des etcd-Datenverzeichnisses vom k3s-Prozess verwaltet und sollte root:root sein.

1.1.13 Stellen Sie sicher, dass die Berechtigungen der admin.conf-Datei auf 600 oder restriktiver gesetzt sind (automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/server/cred/admin.kubeconfig; then stat -c permissions=%a /var/lib/rancher/k3s/server/cred/admin.kubeconfig; fi'

Erwartetes Ergebnis: Die Datei besitzt Berechtigungen von 600; es werden 600 oder restriktivere Berechtigungen erwartet.

Zurückgegebener Wert: 
permissions=600
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chmod 600 /var/lib/rancher/k3s/server/cred/admin.kubeconfig

1.1.14 Stellen Sie sicher, dass der Besitz der admin.conf-Datei auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/server/cred/admin.kubeconfig; then stat -c %U:%G /var/lib/rancher/k3s/server/cred/admin.kubeconfig; fi'

Erwartetes Ergebnis: 'root:root' ist gleich 'root:root'

Zurückgegebener Wert: 
root:root
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chown root:root /var/lib/rancher/k3s/server/cred/admin.kubeconfig

1.1.15 Stellen Sie sicher, dass die Berechtigungen der scheduler.conf-Datei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/server/cred/scheduler.kubeconfig; then stat -c permissions=%a /var/lib/rancher/k3s/server/cred/scheduler.kubeconfig; fi'

Erwartetes Ergebnis: Berechtigungen haben Berechtigungen 600, erwartet 600 oder restriktiver

Zurückgegebener Wert: 
permissions=600
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chmod 600 /var/lib/rancher/k3s/server/cred/scheduler.kubeconfig

1.1.16 Stellen Sie sicher, dass der Besitz der scheduler.conf-Datei auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/server/cred/scheduler.kubeconfig; then stat -c %U:%G /var/lib/rancher/k3s/server/cred/scheduler.kubeconfig; fi'

Erwartetes Ergebnis: 'root:root' ist vorhanden

Zurückgegebener Wert: 
root:root
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chown root:root /var/lib/rancher/k3s/server/cred/scheduler.kubeconfig

1.1.17 Stellen Sie sicher, dass die Berechtigungen der controller-manager.conf-Datei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/server/cred/controller.kubeconfig; then stat -c permissions=%a /var/lib/rancher/k3s/server/cred/controller.kubeconfig; fi'

Erwartetes Ergebnis: Die Berechtigungen sollten 600 betragen bzw. 600 oder restriktiver sein.

Rückgabewert: 
permissions=600
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chmod 600 /var/lib/rancher/k3s/server/cred/controller.kubeconfig

1.1.18 Stellen Sie sicher, dass der Besitz der controller-manager.conf-Datei auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

stat -c %U:%G /var/lib/rancher/k3s/server/cred/controller.kubeconfig

Erwartetes Ergebnis: 'root:root' ist gleich 'root:root'

Rückgabewert: 
root:root
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chown root:root /var/lib/rancher/k3s/server/cred/controller.kubeconfig

1.1.19 Stellen Sie sicher, dass das Kubernetes PKI-Verzeichnis und der Dateibesitz auf root:root gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

stat -c %U:%G /var/lib/rancher/k3s/server/tls

Erwartetes Ergebnis: 'root:root' ist vorhanden

Zurückgegebener Wert: 
root:root
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Dateispeicherort auf Ihrem System) auf dem Steuerungsknoten aus. Zum Beispiel, chown -R root:root /var/lib/rancher/k3s/server/tls

1.1.20 Stellen Sie sicher, dass die Berechtigungen der Kubernetes PKI-Zertifikatdatei auf 600 oder restriktiver gesetzt sind (Manuell)

Ergebnis: WARN

Behebung: Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf dem Master-Knoten aus. Zum Beispiel, chmod -R 600 /var/lib/rancher/k3s/server/tls/*.crt

1.1.21 Stellen Sie sicher, dass die Berechtigungen der Kubernetes PKI-Schlüsseldatei auf 600 gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'stat -c permissions=%a /var/lib/rancher/k3s/server/tls/*.key'

Erwartetes Ergebnis: Die Berechtigungen sollten 600 betragen bzw. 600 oder restriktiver sein.

Rückgabewert: 
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf dem Master-Knoten aus. Zum Beispiel, chmod -R 600 /var/lib/rancher/k3s/server/tls/*.key

1.2 API-Server

1.2.1 Stellen Sie sicher, dass das --anonymous-auth-Argument auf false gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'anonymous-auth'

Erwartetes Ergebnis: '--anonymous-auth' ist gleich 'false'

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --anonymous-auth-Argument auf false. Wenn es auf true gesetzt ist, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alles, was ähnlich wie unten ist.

kube-apiserver-arg:
  - "anonymous-auth=true"

1.2.2 Stellen Sie sicher, dass der --token-auth-file Parameter nicht gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--token-auth-file' ist nicht vorhanden

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Befolgen Sie die Dokumentation und konfigurieren Sie alternative Mechanismen zur Authentifizierung. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alles, was dem Folgenden ähnelt.

kube-apiserver-arg:
  - "token-auth-file=<path>"

1.2.3 Stellen Sie sicher, dass die --DenyServiceExternalIPs nicht gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--enable-admission-plugins' hat nicht 'DenyServiceExternalIPs' ODER '--enable-admission-plugins' ist nicht vorhanden

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s DenyServiceExternalIPs nicht. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen, die dem Folgenden ähneln.

kube-apiserver-arg:
  - "enable-admission-plugins=DenyServiceExternalIPs"

1.2.4 Stellen Sie sicher, dass die --kubelet-client-certificate und --kubelet-client-key Argumente entsprechend gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'kubelet-certificate-authority'

Erwartetes Ergebnis: '--kubelet-client-certificate' ist vorhanden UND '--kubelet-client-key' ist vorhanden

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig stellt K3s automatisch das kubelet-Client-Zertifikat und den Schlüssel zur Verfügung. Sie werden generiert und befinden sich unter /var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt und /var/lib/rancher/k3s/server/tls/client-kube-apiserver.key. Wenn Sie aus irgendeinem Grund Ihr eigenes Zertifikat und Ihren eigenen Schlüssel bereitstellen müssen, können Sie die untenstehenden Parameter in der K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml setzen.

kube-apiserver-arg:
  - "kubelet-client-certificate=<path/to/client-cert-file>"
  - "kubelet-client-key=<path/to/client-key-file>"

1.2.5 Stellen Sie sicher, dass das --kubelet-certificate-authority Argument entsprechend gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'kubelet-certificate-authority'

Erwartetes Ergebnis: '--kubelet-certificate-authority' ist vorhanden

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig stellt K3s automatisch die kubelet CA-Zertifikatdatei unter /var/lib/rancher/k3s/server/tls/server-ca.crt zur Verfügung. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen, die dem Folgenden ähneln.

kube-apiserver-arg:
  - "kubelet-certificate-authority=<path/to/ca-cert-file>"

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

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'

Erwartetes Ergebnis: '--authorization-mode' hat nicht 'AlwaysAllow'

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --authorization-mode nicht auf AlwaysAllow. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "authorization-mode=AlwaysAllow"

1.2.7 Stellen Sie sicher, dass das --authorization-mode Argument Node enthält (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'

Erwartetes Ergebnis: '--authorization-mode' hat 'Node'

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --authorization-mode auf Node und RBAC. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und stellen Sie sicher, dass Sie den authorization-mode nicht überschreiben.

1.2.8 Stellen Sie sicher, dass das --authorization-mode-Argument RBAC (automatisiert) enthält.

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'

Erwartetes Ergebnis: '--authorization-mode' hat 'RBAC'

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --authorization-mode auf Node und RBAC. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und stellen Sie sicher, dass Sie den authorization-mode nicht überschreiben.

1.2.9 Stellen Sie sicher, dass das Admission-Control-Plugin EventRateLimit gesetzt ist (manuell).

Ergebnis: WARN

Behebung: Befolgen Sie die Kubernetes-Dokumentation und setzen Sie die gewünschten Limits in einer Konfigurationsdatei. Bearbeiten Sie dann die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und setzen Sie die folgenden Parameter.

kube-apiserver-arg:
  - "enable-admission-plugins=...,EventRateLimit,..."
  - "admission-control-config-file=<path/to/configuration/file>"

1.2.10 Stellen Sie sicher, dass das Admission-Control-Plugin AlwaysAdmit nicht gesetzt ist (automatisiert).

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'

Erwartetes Ergebnis: '--enable-admission-plugins' hat nicht 'AlwaysAdmit' ODER '--enable-admission-plugins' ist nicht vorhanden.

Rückgabewert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --enable-admission-plugins nicht auf AlwaysAdmit. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "enable-admission-plugins=AlwaysAdmit"

1.2.11 Stellen Sie sicher, dass das Admission-Control-Plugin AlwaysPullImages gesetzt ist (manuell).

Ergebnis: WARN

Behebung: Nach den CIS-Richtlinien ist dies permissiv: "Diese Einstellung könnte Offline- oder isolierte Cluster betreffen, die Bilder vorab geladen haben und keinen Zugriff auf ein Registry haben, um verwendete Bilder zu ziehen." Diese Einstellung ist nicht geeignet für Cluster, die diese Konfiguration verwenden. Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und setzen Sie den folgenden Parameter.

kube-apiserver-arg:
  - "enable-admission-plugins=...,AlwaysPullImages,..."

1.2.12 Stellen Sie sicher, dass das Admission-Control-Plugin SecurityContextDeny gesetzt ist, wenn PodSecurityPolicy nicht verwendet wird (manuell).

Ergebnis: Nicht zutreffend

Erläuterung:

Die Aktivierung der Pod-Sicherheitsrichtlinie wird in K3s v1.25+ nicht mehr unterstützt und führt dazu, dass Anwendungen unerwartet fehlschlagen.

1.2.13 Stellen Sie sicher, dass das Admission-Control-Plugin ServiceAccount gesetzt ist (automatisiert).

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--disable-admission-plugins' ist vorhanden ODER '--disable-admission-plugins' ist nicht vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --disable-admission-plugins auf nichts. Befolgen Sie die Dokumentation und erstellen Sie ServiceAccount-Objekte gemäß Ihrer Umgebung. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "disable-admission-plugins=ServiceAccount"

1.2.14 Stellen Sie sicher, dass das Admission-Control-Plugin NamespaceLifecycle gesetzt ist (automatisiert).

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--disable-admission-plugins' ist vorhanden ODER '--disable-admission-plugins' ist nicht vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --disable-admission-plugins auf nichts. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "disable-admission-plugins=...,NamespaceLifecycle,..."

1.2.15 Stellen Sie sicher, dass das Admission Control-Plugin NodeRestriction gesetzt ist (automatisiert).

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'

Erwartetes Ergebnis: '--enable-admission-plugins' hat 'NodeRestriction'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --enable-admission-plugins auf NodeRestriction. Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, überprüfen Sie, ob Sie die Admission-Plugins nicht überschreiben. Wenn Sie dies tun, fügen Sie NodeRestriction in die Liste ein.

kube-apiserver-arg:
  - "enable-admission-plugins=...,NodeRestriction,..."

1.2.16 Stellen Sie sicher, dass das --secure-port-Argument nicht auf 0 gesetzt ist - Hinweis: Diese Empfehlung ist veraltet und wird gemäß dem Konsensprozess gelöscht (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'secure-port'

Erwartetes Ergebnis: '--secure-port' ist größer als 0 ODER '--secure-port' ist nicht vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s den sicheren Port auf 6444. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "secure-port=<PORT>"

1.2.17 Stellen Sie sicher, dass das --profiling-Argument auf false gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'profiling'

Erwartetes Ergebnis: '--profiling' ist gleich 'false'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --profiling-Argument auf false. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "profiling=true"

1.2.18 Stellen Sie sicher, dass das --audit-log-path-Argument gesetzt ist (Manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--audit-log-path' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und setzen Sie den Parameter audit-log-path auf einen geeigneten Pfad und eine Datei, in die Sie Audit-Logs schreiben möchten, zum Beispiel:

kube-apiserver-arg:
  - "audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log"

1.2.19 Stellen Sie sicher, dass das --audit-log-maxage-Argument auf 30 oder entsprechend gesetzt ist (Manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--audit-log-maxage' ist größer oder gleich 30

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml auf dem Steuerungsknoten und setzen Sie den Parameter audit-log-maxage auf 30 oder auf eine angemessene Anzahl von Tagen, zum Beispiel:

kube-apiserver-arg:
  - "audit-log-maxage=30"

1.2.20 Stellen Sie sicher, dass das --audit-log-maxbackup-Argument auf 10 oder entsprechend gesetzt ist (Manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--audit-log-maxbackup' ist größer oder gleich 10

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml auf dem Steuerungsknoten und setzen Sie den Parameter audit-log-maxbackup auf 10 oder auf einen geeigneten Wert. Beispiel:

kube-apiserver-arg:
  - "audit-log-maxbackup=10"

1.2.21 Stellen Sie sicher, dass das --audit-log-maxsize-Argument auf 100 oder entsprechend eingestellt ist (Manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--audit-log-maxsize' ist größer oder gleich 100

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml auf dem Steuerungsknoten und setzen Sie den Parameter audit-log-maxsize auf eine angemessene Größe in MB. Beispiel:

kube-apiserver-arg:
  - "audit-log-maxsize=100"

1.2.22 Stellen Sie sicher, dass das --request-timeout-Argument entsprechend eingestellt ist (Manuell)

Ergebnis: WARN

Behebung: Nach den CIS-Richtlinien wird empfohlen, dieses Limit entsprechend festzulegen und das Standardlimit von 60 Sekunden nur bei Bedarf zu ändern. Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und setzen Sie den untenstehenden Parameter, falls erforderlich. Beispiel:

kube-apiserver-arg:
  - "request-timeout=300s"

1.2.23 Stellen Sie sicher, dass das --service-account-lookup-Argument auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--service-account-lookup' ist nicht vorhanden ODER '--service-account-lookup' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --service-account-lookup-Argument nicht. Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und setzen Sie das service-account-lookup. Beispiel:

kube-apiserver-arg:
  - "service-account-lookup=true"

Alternativ können Sie den Parameter service-account-lookup aus dieser Datei entfernen, damit das Standardverhalten wirksam wird.

1.2.24 Stellen Sie sicher, dass das --service-account-key-file-Argument entsprechend eingestellt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1

Erwartetes Ergebnis: '--service-account-key-file' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

K3s generiert und setzt automatisch die ServiceAccount-Schlüsseldatei. Sie befindet sich unter /var/lib/rancher/k3s/server/tls/service.key. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "service-account-key-file=<path>"

1.2.25 Stellen Sie sicher, dass die Argumente --etcd-certfile und --etcd-keyfile entsprechend eingestellt sind (Automatisiert)

Ergebnis: PASS

Revision:

if [ "$(journalctl -u k3s | grep -m1 'Managed etcd cluster' | wc -l)" -gt 0 ]; then
  journalctl -D /var/log/journal -u k3s | grep -m1 'Running kube-apiserver' | tail -n1
else
  echo "--etcd-certfile AND --etcd-keyfile"
fi

Erwartetes Ergebnis: '--etcd-certfile' ist vorhanden UND '--etcd-keyfile' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

K3s generiert und setzt automatisch die etcd-Zertifikats- und Schlüsseldateien. Sie befinden sich unter /var/lib/rancher/k3s/server/tls/etcd/client.crt und /var/lib/rancher/k3s/server/tls/etcd/client.key. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "etcd-certfile=<path>"
  - "etcd-keyfile=<path>"

1.2.26 Stellen Sie sicher, dass die --tls-cert-file und --tls-private-key-file Argumente entsprechend gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -D /var/log/journal -u k3s | grep -A1 'Running kube-apiserver' | tail -n2

Erwartetes Ergebnis: '--tls-cert-file' ist vorhanden UND '--tls-private-key-file' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-scheduler --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --bind-address=127.0.0.1 --kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --profiling=false --secure-port=10259"
Behebung:

Standardmäßig generiert K3s automatisch das TLS-Zertifikat und den privaten Schlüssel für den apiserver. Sie werden generiert und befinden sich unter /var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt und /var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "tls-cert-file=<path>"
  - "tls-private-key-file=<path>"

1.2.27 Stellen Sie sicher, dass das --client-ca-file Argument entsprechend gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'client-ca-file'

Erwartetes Ergebnis: '--client-ca-file' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig stellt K3s die Datei der Client-Zertifizierungsstelle zur Verfügung. Sie wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/client-ca.crt. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "client-ca-file=<path>"

1.2.28 Stellen Sie sicher, dass das --etcd-cafile Argument entsprechend gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-cafile'

Erwartetes Ergebnis: '--etcd-cafile' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig stellt K3s die Datei der etcd-Zertifizierungsstelle zur Verfügung. Sie wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/client-ca.crt. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-apiserver-arg:
  - "etcd-cafile=<path>"

1.2.29 Stellen Sie sicher, dass das --encryption-provider-config Argument entsprechend gesetzt ist (Manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'encryption-provider-config'

Erwartetes Ergebnis: '--encryption-provider-config' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

K3s kann so konfiguriert werden, dass Verschlüsselungsanbieter verwendet werden, um Geheimnisse im Ruhezustand zu verschlüsseln. Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml auf dem Steuerungsknoten und setzen Sie den folgenden Parameter. secrets-encryption: true. Die Verschlüsselung von Geheimnissen kann dann mit dem k3s secrets-encrypt Kommandozeilenwerkzeug verwaltet werden. Falls erforderlich, finden Sie die generierte Verschlüsselungskonfiguration unter /var/lib/rancher/k3s/server/cred/encryption-config.json.

1.2.30 Stellen Sie sicher, dass die Verschlüsselungsanbieter angemessen konfiguriert sind (Manuell)

Ergebnis: PASS

Revision:

ENCRYPTION_PROVIDER_CONFIG=$(journalctl -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep -- --encryption-provider-config | sed 's%.*encryption-provider-config[= ]\([^ ]*\).*%\1%')
if test -e $ENCRYPTION_PROVIDER_CONFIG; then grep -o 'providers\"\:\[.*\]' $ENCRYPTION_PROVIDER_CONFIG | grep -o "[A-Za-z]*" | head -2 | tail -1  | sed 's/^/provider=/'; fi

Erwartetes Ergebnis: 'provider' enthält gültige Elemente aus 'aescbc,kms,secretbox'

Zurückgegebener Wert: 
provider=aescbc
Behebung:

K3s kann so konfiguriert werden, dass Verschlüsselungsanbieter verwendet werden, um Geheimnisse im Ruhezustand zu verschlüsseln. K3s wird den aescbc-Anbieter nutzen. Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml auf dem Steuerungsknoten und setzen Sie den folgenden Parameter. secrets-encryption: true. Die Verschlüsselung von Geheimnissen kann dann mit dem k3s secrets-encrypt Kommandozeilenwerkzeug verwaltet werden. Falls erforderlich, finden Sie die generierte Verschlüsselungskonfiguration unter /var/lib/rancher/k3s/server/cred/encryption-config.json.

1.2.31 Stellen Sie sicher, dass der API-Server nur starke kryptografische Chiffren verwendet (automatisiert)

Ergebnis: PASS

Revision:

journalctl -D /var/log/journal -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'tls-cipher-suites'

Erwartetes Ergebnis: '--tls-cipher-suites' enthält gültige Elemente aus 'TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig erfüllt der K3s kube-apiserver diesen Test. Änderungen an diesen Werten können Regressionen verursachen, stellen Sie daher sicher, dass alle apiserver-Clients die neue TLS-Konfiguration unterstützen, bevor Sie sie in Produktionsbereitstellungen anwenden. Wenn eine benutzerdefinierte TLS-Konfiguration erforderlich ist, ziehen Sie in Betracht, auch eine benutzerdefinierte Version dieser Regel zu erstellen, die Ihren Anforderungen entspricht. Wenn diese Überprüfung fehlschlägt, entfernen Sie alle benutzerdefinierten Konfigurationen zu tls-cipher-suites oder aktualisieren Sie die Datei /etc/rancher/k3s/config.yaml, um mit den Standardeinstellungen übereinzustimmen, indem Sie Folgendes hinzufügen:

kube-apiserver-arg:
  - "tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305"

1.3 Controller-Manager

1.3.1 Stellen Sie sicher, dass das Argument --terminated-pod-gc-threshold angemessen gesetzt ist (manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'terminated-pod-gc-threshold'

Erwartetes Ergebnis: '--terminated-pod-gc-threshold' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --bind-address=127.0.0.1 --cluster-cidr=10.42.0.0/16 --cluster-signing-kube-apiserver-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kube-apiserver-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kubelet-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-serving-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-kubelet-serving-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --cluster-signing-legacy-unknown-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-legacy-unknown-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --configure-cloud-routes=false --controllers=*,tokencleaner,-service,-route,-cloud-node-lifecycle --feature-gates=JobTrackingWithFinalizers=true --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --profiling=false --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt --secure-port=10257 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --terminated-pod-gc-threshold=10 --use-service-account-credentials=true"
Behebung:

Bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml auf dem Steuerungsknoten und setzen Sie den --terminated-pod-gc-threshold auf einen angemessenen Schwellenwert,

kube-controller-manager-arg:
  - "terminated-pod-gc-threshold=10"

1.3.2 Stellen Sie sicher, dass das Argument --profiling auf false gesetzt ist (automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'profiling'

Erwartetes Ergebnis: '--profiling' ist gleich 'false'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --bind-address=127.0.0.1 --cluster-cidr=10.42.0.0/16 --cluster-signing-kube-apiserver-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kube-apiserver-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kubelet-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-serving-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-kubelet-serving-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --cluster-signing-legacy-unknown-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-legacy-unknown-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --configure-cloud-routes=false --controllers=*,tokencleaner,-service,-route,-cloud-node-lifecycle --feature-gates=JobTrackingWithFinalizers=true --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --profiling=false --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt --secure-port=10257 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --terminated-pod-gc-threshold=10 --use-service-account-credentials=true"
Behebung:

Standardmäßig setzt K3s das --profiling-Argument auf false. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-controller-manager-arg:
  - "profiling=true"

1.3.3 Stellen Sie sicher, dass das Argument --use-service-account-credentials auf true gesetzt ist (automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'use-service-account-credentials'

Erwartetes Ergebnis: '--use-service-account-credentials' ist nicht gleich 'false'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --bind-address=127.0.0.1 --cluster-cidr=10.42.0.0/16 --cluster-signing-kube-apiserver-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kube-apiserver-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kubelet-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-serving-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-kubelet-serving-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --cluster-signing-legacy-unknown-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-legacy-unknown-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --configure-cloud-routes=false --controllers=*,tokencleaner,-service,-route,-cloud-node-lifecycle --feature-gates=JobTrackingWithFinalizers=true --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --profiling=false --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt --secure-port=10257 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --terminated-pod-gc-threshold=10 --use-service-account-credentials=true"
Behebung:

Standardmäßig setzt K3s das Argument --use-service-account-credentials auf true. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-controller-manager-arg:
  - "use-service-account-credentials=false"

1.3.4 Stellen Sie sicher, dass das Argument --service-account-private-key-file angemessen gesetzt ist (automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'service-account-private-key-file'

Erwartetes Ergebnis: '--service-account-private-key-file' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --bind-address=127.0.0.1 --cluster-cidr=10.42.0.0/16 --cluster-signing-kube-apiserver-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kube-apiserver-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kubelet-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-serving-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-kubelet-serving-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --cluster-signing-legacy-unknown-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-legacy-unknown-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --configure-cloud-routes=false --controllers=*,tokencleaner,-service,-route,-cloud-node-lifecycle --feature-gates=JobTrackingWithFinalizers=true --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --profiling=false --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt --secure-port=10257 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --terminated-pod-gc-threshold=10 --use-service-account-credentials=true"
Behebung:

Standardmäßig stellt K3s automatisch die private Schlüsseldatei des Dienstkontos zur Verfügung. Sie wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/service.current.key. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-controller-manager-arg:
  - "service-account-private-key-file=<path>"

1.3.5 Stellen Sie sicher, dass das --root-ca-file Argument entsprechend gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'root-ca-file'

Erwartetes Ergebnis: '--root-ca-file' ist vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --bind-address=127.0.0.1 --cluster-cidr=10.42.0.0/16 --cluster-signing-kube-apiserver-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kube-apiserver-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kubelet-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-serving-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-kubelet-serving-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --cluster-signing-legacy-unknown-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-legacy-unknown-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --configure-cloud-routes=false --controllers=*,tokencleaner,-service,-route,-cloud-node-lifecycle --feature-gates=JobTrackingWithFinalizers=true --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --profiling=false --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt --secure-port=10257 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --terminated-pod-gc-threshold=10 --use-service-account-credentials=true"
Behebung:

Standardmäßig stellt K3s automatisch die Root-CA-Datei bereit. Sie wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/server-ca.crt. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-controller-manager-arg:
  - "root-ca-file=<path>"

1.3.6 Stellen Sie sicher, dass das RotateKubeletServerCertificate Argument auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-controller-manager' | tail -n1

Erwartetes Ergebnis: '--feature-gates' hat nicht 'RotateKubeletServerCertificate=false' ODER '--feature-gates' ist nicht vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --bind-address=127.0.0.1 --cluster-cidr=10.42.0.0/16 --cluster-signing-kube-apiserver-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kube-apiserver-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-client-cert-file=/var/lib/rancher/k3s/server/tls/client-ca.nochain.crt --cluster-signing-kubelet-client-key-file=/var/lib/rancher/k3s/server/tls/client-ca.key --cluster-signing-kubelet-serving-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-kubelet-serving-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --cluster-signing-legacy-unknown-cert-file=/var/lib/rancher/k3s/server/tls/server-ca.nochain.crt --cluster-signing-legacy-unknown-key-file=/var/lib/rancher/k3s/server/tls/server-ca.key --configure-cloud-routes=false --controllers=*,tokencleaner,-service,-route,-cloud-node-lifecycle --feature-gates=JobTrackingWithFinalizers=true --kubeconfig=/var/lib/rancher/k3s/server/cred/controller.kubeconfig --profiling=false --root-ca-file=/var/lib/rancher/k3s/server/tls/server-ca.crt --secure-port=10257 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --terminated-pod-gc-threshold=10 --use-service-account-credentials=true"
Behebung:

Standardmäßig setzt K3s das RotateKubeletServerCertificate Feature-Gate nicht. Wenn Sie dieses Feature-Gate aktiviert haben, sollten Sie es entfernen. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-controller-manager-arg:
  - "feature-gate=RotateKubeletServerCertificate"

1.3.7 Stellen Sie sicher, dass das --bind-address Argument auf 127.0.0.1 gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

/bin/ps -ef | grep containerd | grep -v grep

Erwartetes Ergebnis: '--bind-address' ist vorhanden ODER '--bind-address' ist nicht vorhanden

Zurückgegebener Wert: 
root        2372    2354  4 19:01 ?        00:00:05 containerd -c /var/lib/rancher/k3s/agent/etc/containerd/config.toml -a /run/k3s/containerd/containerd.sock --state /run/k3s/containerd --root /var/lib/rancher/k3s/agent/containerd
root        3128       1  0 19:01 ?        00:00:00 /var/lib/rancher/k3s/data/0f1a87835be3817408b496b439fddb9ea54cab4298db472792bb1b1cbdc210bc/bin/containerd-shim-runc-v2 -namespace k8s.io -id 878d74b0d77d904ec40cd1db71956f2edeb68ab420227a5a42e6d25f249a140a -address /run/k3s/containerd/containerd.sock
root        3239       1  0 19:01 ?        00:00:00 /var/lib/rancher/k3s/data/0f1a87835be3817408b496b439fddb9ea54cab4298db472792bb1b1cbdc210bc/bin/containerd-shim-runc-v2 -namespace k8s.io -id d00cc363af40aee36210e396597e4c02712ae99535be21d204849dc33a22af88 -address /run/k3s/containerd/containerd.sock
root        3293       1  0 19:01 ?        00:00:00 /var/lib/rancher/k3s/data/0f1a87835be3817408b496b439fddb9ea54cab4298db472792bb1b1cbdc210bc/bin/containerd-shim-runc-v2 -namespace k8s.io -id 5df076fa9547c555a2231b9a9a7cbb44021eaa1ab68c9b59b13da960697143f6 -address /run/k3s/containerd/containerd.sock
root        4557       1  0 19:02 ?        00:00:00 /var/lib/rancher/k3s/data/0f1a87835be3817408b496b439fddb9ea54cab4298db472792bb1b1cbdc210bc/bin/containerd-shim-runc-v2 -namespace k8s.io -id f6483b71bcb7ea23356003921a7d90cf638b8f9e473728f3b28dc67163e0fa2d -address /run/k3s/containerd/containerd.sock
root        4644       1  0 19:02 ?        00:00:00 /var/lib/rancher/k3s/data/0f1a87835be3817408b496b439fddb9ea54cab4298db472792bb1b1cbdc210bc/bin/containerd-shim-runc-v2 -namespace k8s.io -id 4d8ceb2620c4e0501a49dc9192fc56d035e76bc79a2c6072fee8619730006233 -address /run/k3s/containerd/containerd.sock
Behebung:

Standardmäßig setzt K3s das --bind-address Argument auf 127.0.0.1. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-controller-manager-arg:
  - "bind-address=<IP>"

1.4 Scheduler

1.4.1 Stellen Sie sicher, dass das --profiling Argument auf false gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -D /var/log/journal -u k3s | grep 'Running kube-scheduler' | tail -n1

Erwartetes Ergebnis: '--profiling' ist gleich 'false'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-scheduler --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --bind-address=127.0.0.1 --kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --profiling=false --secure-port=10259"
Behebung:

Standardmäßig setzt K3s das --profiling Argument auf false. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-scheduler-arg:
  - "profiling=true"

1.4.2 Stellen Sie sicher, dass das --bind-address Argument auf 127.0.0.1 gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s | grep 'Running kube-scheduler' | tail -n1 | grep 'bind-address'

Erwartetes Ergebnis: '--bind-address' ist gleich '127.0.0.1' ODER '--bind-address' ist nicht vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-scheduler --authentication-kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --authorization-kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --bind-address=127.0.0.1 --kubeconfig=/var/lib/rancher/k3s/server/cred/scheduler.kubeconfig --profiling=false --secure-port=10259"
Behebung:

Standardmäßig setzt K3s das --bind-address Argument auf 127.0.0.1. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten.

kube-scheduler-arg:
  - "bind-address=<IP>"

2 Etcd Knotenkonfiguration

2.1 Stellen Sie sicher, dass die Argumente --cert-file und --key-file entsprechend gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.client-transport-security.cert-file' ist gleich '/var/lib/rancher/k3s/server/tls/etcd/server-client.crt' UND '.client-transport-security.key-file' ist gleich '/var/lib/rancher/k3s/server/tls/etcd/server-client.key'

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd generiert K3s Zertifikats- und Schlüsseldateien für etcd. Diese befinden sich in /var/lib/rancher/k3s/server/tls/etcd/. Wenn diese Überprüfung fehlschlägt, stellen Sie sicher, dass die Konfigurationsdatei /var/lib/rancher/k3s/server/db/etcd/config nicht geändert wurde, um benutzerdefinierte Zertifikats- und Schlüsseldateien zu verwenden.

2.2 Stellen Sie sicher, dass das Argument --client-cert-auth auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.client-transport-security.client-cert-auth' ist gleich 'true'

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd setzt K3s den Parameter --client-cert-auth auf true. Wenn diese Überprüfung fehlschlägt, stellen Sie sicher, dass die Konfigurationsdatei /var/lib/rancher/k3s/server/db/etcd/config nicht geändert wurde, um die Authentifizierung mit Client-Zertifikaten zu deaktivieren.

2.3 Stellen Sie sicher, dass das Argument --auto-tls nicht auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.client-transport-security.auto-tls' ist vorhanden ODER '.client-transport-security.auto-tls' ist nicht vorhanden

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd setzt K3s den Parameter --auto-tls nicht. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die Spezifikationsdatei des etcd-Pods /var/lib/rancher/k3s/server/db/etcd/config auf dem Master-Knoten und entfernen Sie entweder den Parameter --auto-tls oder setzen Sie ihn auf false.
client-transport-security:
auto-tls: false

2.4 Stellen Sie sicher, dass die Argumente --peer-cert-file und --peer-key-file entsprechend gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.peer-transport-security.cert-file' ist gleich '/var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt' UND '.peer-transport-security.key-file' ist gleich '/var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key'

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd generiert K3s Peer-Zertifikats- und Schlüsseldateien für etcd. Diese befinden sich in /var/lib/rancher/k3s/server/tls/etcd/. Wenn diese Überprüfung fehlschlägt, stellen Sie sicher, dass die Konfigurationsdatei /var/lib/rancher/k3s/server/db/etcd/config nicht geändert wurde, um benutzerdefinierte Peer-Zertifikats- und Schlüsseldateien zu verwenden.

2.5 Stellen Sie sicher, dass das --peer-client-cert-auth-Argument auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.peer-transport-security.client-cert-auth' ist gleich 'true'

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd setzt K3s den --peer-cert-auth-Parameter auf true. Wenn diese Überprüfung fehlschlägt, stellen Sie sicher, dass die Konfigurationsdatei /var/lib/rancher/k3s/server/db/etcd/config nicht geändert wurde, um die Authentifizierung des Peer-Client-Zertifikats zu deaktivieren.

2.6 Stellen Sie sicher, dass das --peer-auto-tls-Argument nicht auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.peer-transport-security.auto-tls' ist vorhanden ODER '.peer-transport-security.auto-tls' ist nicht vorhanden

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie auf sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht zutreffend. Beim Betrieb mit embedded-etcd setzt K3s den --peer-auto-tls-Parameter nicht. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die etcd-Pod-Spezifikationsdatei /var/lib/rancher/k3s/server/db/etcd/config auf dem Master-Knoten und entfernen Sie entweder den --peer-auto-tls-Parameter oder setzen Sie ihn auf false. peer-transport-security: auto-tls: false

2.7 Stellen Sie sicher, dass eine eindeutige Zertifizierungsstelle für etcd verwendet wird (Automatisiert)

Ergebnis: PASS

Revision:

Erwartetes Ergebnis: '.peer-transport-security.trusted-ca-file' ist gleich '/var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt'

Zurückgegebener Wert: 
advertise-client-urls: https://10.10.10.100:2379
client-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/server-ca.crt
data-dir: /var/lib/rancher/k3s/server/db/etcd
election-timeout: 5000
experimental-initial-corrupt-check: true
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-4a89bd20=https://10.10.10.100:2380
initial-cluster-state: new
listen-client-http-urls: https://127.0.0.1:2382
listen-client-urls: https://127.0.0.1:2379,https://10.10.10.100:2379
listen-metrics-urls: http://127.0.0.1:2381
listen-peer-urls: https://127.0.0.1:2380,https://10.10.10.100:2380
log-outputs:
- stderr
logger: zap
name: server-0-4a89bd20
peer-transport-security:
  cert-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.crt
  client-cert-auth: true
  key-file: /var/lib/rancher/k3s/server/tls/etcd/peer-server-client.key
  trusted-ca-file: /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt
snapshot-count: 10000
Behebung:

Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Prüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd generiert K3s eine eindeutige CA für etcd. Diese befindet sich unter /var/lib/rancher/k3s/server/tls/etcd/peer-ca.crt. Wenn diese Überprüfung fehlschlägt, stellen Sie sicher, dass die Konfigurationsdatei /var/lib/rancher/k3s/server/db/etcd/config nicht geändert wurde, um eine gemeinsame CA zu verwenden.

4.1 Konfigurationsdateien für Arbeitsknoten

4.1.1 Stellen Sie sicher, dass die Berechtigungen der kubelet-Dienstdatei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Der kubelet ist im k3s-Prozess eingebettet. Es gibt keine kubelet-Dienstdatei, alle Konfigurationen werden zur Laufzeit als Argumente übergeben.

4.1.2 Stellen Sie sicher, dass der Eigentümer der kubelet-Dienstdatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Der kubelet ist im k3s-Prozess eingebettet. Es gibt keine kubelet-Dienstdatei, alle Konfigurationen werden zur Laufzeit als Argumente übergeben.

Alle Konfigurationen werden zur Laufzeit des Containers als Argumente übergeben.

4.1.3 Wenn die Proxy-Kubeconfig-Datei vorhanden ist, stellen Sie sicher, dass die Berechtigungen auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig; then stat -c permissions=%a /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig; fi'

Erwartetes Ergebnis: Berechtigungen haben die Berechtigungen 600, erwartet 600 oder restriktiver

Zurückgegebener Wert: 
permissions=600
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf jedem Arbeitsknoten aus. Zum Beispiel, chmod 600 /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig

4.1.4 Wenn die Proxy-Kubeconfig-Datei vorhanden ist, stellen Sie sicher, dass der Eigentümer auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig; then stat -c %U:%G /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig; fi'

Erwartetes Ergebnis: 'root:root' ist vorhanden

Zurückgegebener Wert: 
root:root
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf jedem Arbeitsknoten aus. Zum Beispiel, chown root:root /var/lib/rancher/k3s/agent/kubeproxy.kubeconfig

4.1.5 Stellen Sie sicher, dass die --kubeconfig kubelet.conf-Dateiberechtigungen auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test -e /var/lib/rancher/k3s/agent/kubelet.kubeconfig; then stat -c permissions=%a /var/lib/rancher/k3s/agent/kubelet.kubeconfig; fi'

Erwartetes Ergebnis: Berechtigungen haben die Berechtigungen 600, erwartet 600 oder restriktiver

Zurückgegebener Wert: 
permissions=600
Behebung:

Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf jedem Arbeitsknoten aus. Zum Beispiel, chmod 600 /var/lib/rancher/k3s/agent/kubelet.kubeconfig

4.1.6 Stellen Sie sicher, dass der Eigentümer der --kubeconfig kubelet.conf-Datei auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

stat -c %U:%G /var/lib/rancher/k3s/agent/kubelet.kubeconfig

Erwartetes Ergebnis: 'root:root' ist vorhanden

Zurückgegebener Wert: 
root:root
Behebung:

Führen Sie den untenstehenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf jedem Arbeitsknoten aus. Zum Beispiel, chown root:root /var/lib/rancher/k3s/agent/kubelet.kubeconfig

4.1.7 Stellen Sie sicher, dass die Berechtigungen der Zertifizierungsstellen-Datei auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: PASS

Revision:

stat -c permissions=%a /var/lib/rancher/k3s/agent/client-ca.crt

Erwartetes Ergebnis: Die Berechtigungen sind auf 600 gesetzt, erwartet 600 oder restriktiver

Zurückgegebener Wert: 
permissions=600
Behebung:

Führen Sie den folgenden Befehl aus, um die Dateiberechtigungen der --client-ca-file chmod 600 /var/lib/rancher/k3s/agent/client-ca.crt zu ändern.

4.1.8 Stellen Sie sicher, dass die Eigentümerschaft der Client-Zertifizierungsstellen-Datei auf root:root gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

stat -c %U:%G /var/lib/rancher/k3s/agent/client-ca.crt

Erwartetes Ergebnis: 'root:root' ist gleich 'root:root'

Zurückgegebener Wert: 
root:root
Behebung:

Führen Sie den folgenden Befehl aus, um den Eigentümer der --client-ca-file zu ändern. chown root:root /var/lib/rancher/k3s/agent/client-ca.crt

4.1.9 Stellen Sie sicher, dass die kubelet --config-Konfigurationsdatei Berechtigungen hat, die auf 600 oder restriktiver gesetzt sind (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Das Kubelet ist im k3s-Prozess eingebettet. Es gibt keine Kubelet-Konfigurationsdatei, alle Konfigurationen werden zur Laufzeit als Argumente übergeben.

4.1.10 Stellen Sie sicher, dass die Eigentümerschaft der kubelet --config-Konfigurationsdatei auf root:root gesetzt ist (Automatisiert)

Ergebnis: Nicht zutreffend

Erläuterung:

Das Kubelet ist im k3s-Prozess eingebettet. Es gibt keine Kubelet-Konfigurationsdatei, alle Konfigurationen werden zur Laufzeit als Argumente übergeben.

4.2 Kubelet

4.2.1 Stellen Sie sicher, dass das --anonymous-auth-Argument auf false gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

/bin/sh -c 'if test $(journalctl -D /var/log/journal -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -D /var/log/journal -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "anonymous-auth" | grep -v grep; else echo "--anonymous-auth=false"; fi'

Erwartetes Ergebnis: '--anonymous-auth' ist gleich 'false'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s die --anonymous-auth auf false. Wenn Sie dies auf einen anderen Wert gesetzt haben, sollten Sie es wieder auf false setzen. Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, entfernen Sie alle Zeilen, die ähnlich wie unten sind.

kubelet-arg:
  - "anonymous-auth=true"

Wenn Sie die Befehlszeile verwenden, bearbeiten Sie die K3s-Dienstdatei und entfernen Sie das untenstehende Argument. --kubelet-arg="anonymous-auth=true" Basierend auf Ihrem System starten Sie den k3s-Dienst neu. Zum Beispiel,
systemctl daemon-reload
systemctl restart k3s.service

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

Ergebnis: PASS

Revision:

/bin/sh -c 'if test $(journalctl -D /var/log/journal -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -D /var/log/journal -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "authorization-mode"; else echo "--authorization-mode=Webhook"; fi'

Erwartetes Ergebnis: '--authorization-mode' hat nicht 'AlwaysAllow'

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig setzt K3s das --authorization-mode nicht auf AlwaysAllow. Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, entfernen Sie alle Zeilen, die ähnlich wie unten sind.

kubelet-arg:
  - "authorization-mode=AlwaysAllow"

Wenn Sie die Befehlszeile verwenden, bearbeiten Sie die K3s-Dienstdatei und entfernen Sie das untenstehende Argument. --kubelet-arg="authorization-mode=AlwaysAllow" Basierend auf Ihrem System starten Sie den k3s-Dienst neu. Zum Beispiel,
systemctl daemon-reload
systemctl restart k3s.service

4.2.3 Stellen Sie sicher, dass das --client-ca-file-Argument angemessen gesetzt ist (Automatisiert).

Ergebnis: PASS

Revision:

/bin/sh -c 'if test $(journalctl -D /var/log/journal -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -D /var/log/journal -u k3s | grep "Running kube-apiserver" | tail -n1 | grep "client-ca-file"; else echo "--client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt"; fi'

Erwartetes Ergebnis: '--client-ca-file' ist vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:28 server-0 k3s[2354]: time="2024-08-09T19:01:28Z" level=info msg="Running kube-apiserver --admission-control-config-file=/var/lib/rancher/k3s/server/psa.yaml --advertise-address=10.10.10.100 --advertise-port=6443 --allow-privileged=true --anonymous-auth=false --api-audiences=https://kubernetes.default.svc.cluster.local,k3s --audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100 --audit-log-path=/var/lib/rancher/k3s/server/logs/audit.log --audit-policy-file=/var/lib/rancher/k3s/server/audit.yaml --authorization-mode=Node,RBAC --bind-address=127.0.0.1 --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --client-ca-file=/var/lib/rancher/k3s/server/tls/client-ca.crt --egress-selector-config-file=/var/lib/rancher/k3s/server/etc/egress-selector-config.yaml --enable-admission-plugins=NodeRestriction --enable-aggregator-routing=true --enable-bootstrap-token-auth=true --encryption-provider-config=/var/lib/rancher/k3s/server/cred/encryption-config.json --etcd-cafile=/var/lib/rancher/k3s/server/tls/etcd/server-ca.crt --etcd-certfile=/var/lib/rancher/k3s/server/tls/etcd/client.crt --etcd-keyfile=/var/lib/rancher/k3s/server/tls/etcd/client.key --etcd-servers=https://127.0.0.1:2379 --feature-gates=JobTrackingWithFinalizers=true --kubelet-certificate-authority=/var/lib/rancher/k3s/server/tls/server-ca.crt --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.crt --kubelet-client-key=/var/lib/rancher/k3s/server/tls/client-kube-apiserver.key --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname --profiling=false --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --requestheader-allowed-names=system:auth-proxy --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group --requestheader-username-headers=X-Remote-User --secure-port=6444 --service-account-issuer=https://kubernetes.default.svc.cluster.local --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.current.key --service-cluster-ip-range=10.43.0.0/16 --service-node-port-range=30000-32767 --storage-backend=etcd3 --tls-cert-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/server/tls/serving-kube-apiserver.key"
Behebung:

Standardmäßig stellt K3s automatisch das Client-CA-Zertifikat für das Kubelet zur Verfügung. Es wird generiert und befindet sich unter /var/lib/rancher/k3s/agent/client-ca.crt.

4.2.4 Überprüfen Sie, dass das --read-only-port-Argument auf 0 gesetzt ist (Automatisiert).

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--read-only-port' ist gleich '0' ODER '--read-only-port' ist nicht vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Standardmäßig setzt K3s das --read-only-port auf 0. Wenn Sie dies auf einen anderen Wert gesetzt haben, sollten Sie es wieder auf 0 setzen. Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, entfernen Sie alle Zeilen, die ähnlich wie unten sind.

kubelet-arg:
  - "read-only-port=XXXX"

Wenn Sie die Befehlszeile verwenden, bearbeiten Sie die K3s-Dienstdatei und entfernen Sie das untenstehende Argument. --kubelet-arg="read-only-port=XXXX" Basierend auf Ihrem System starten Sie den k3s-Dienst neu. Zum Beispiel,
systemctl daemon-reload
systemctl restart k3s.service

4.2.5 Stellen Sie sicher, dass das --streaming-connection-idle-timeout-Argument nicht auf 0 gesetzt ist (Manuell).

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--streaming-connection-idle-timeout' ist nicht gleich '0' ODER '--streaming-connection-idle-timeout' ist nicht vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, setzen Sie den folgenden Parameter auf einen geeigneten Wert.

kubelet-arg:
  - "streaming-connection-idle-timeout=5m"

Wenn Sie die Befehlszeile verwenden, führen Sie K3s mit --kubelet-arg="streaming-connection-idle-timeout=5m" aus. Starten Sie den k3s-Dienst je nach System neu. Zum Beispiel: systemctl restart k3s.service

4.2.6 Stellen Sie sicher, dass das Argument --make-iptables-util-chains auf true (automatisiert) gesetzt ist.

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--make-iptables-util-chains' ist gleich 'true' ODER '--make-iptables-util-chains' ist nicht vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, setzen Sie den folgenden Parameter.

kubelet-arg:
  - "make-iptables-util-chains=true"

Wenn Sie die Befehlszeile verwenden, führen Sie K3s mit --kubelet-arg="make-iptables-util-chains=true" aus. Starten Sie den k3s-Dienst je nach System neu. Zum Beispiel: systemctl restart k3s.service

4.2.7 Stellen Sie sicher, dass das Argument --hostname-override nicht gesetzt ist (automatisiert).

Ergebnis: Nicht zutreffend

Erläuterung:

Standardmäßig setzt K3s das Argument --hostname-override. Laut CIS-Richtlinien dient dies der Einhaltung von Cloud-Anbietern, die dieses Flag benötigen, um sicherzustellen, dass der Hostname mit den Knotennamen übereinstimmt.

4.2.8 Stellen Sie sicher, dass das Argument eventRecordQPS auf ein Niveau gesetzt ist, das eine angemessene Ereigniserfassung gewährleistet (manuell).

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--event-qps' ist größer oder gleich 0 ODER '--event-qps' ist nicht vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Standardmäßig setzt K3s den event-qps auf 0. Sollten Sie dies ändern wollen, wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, setzen Sie den folgenden Parameter auf einen geeigneten Wert.

kubelet-arg:
  - "event-qps=<value>"

Wenn Sie die Befehlszeile verwenden, führen Sie K3s mit --kubelet-arg="event-qps=<value>" aus. Starten Sie den k3s-Dienst je nach System neu. Zum Beispiel: systemctl restart k3s.service

4.2.9 Stellen Sie sicher, dass die Argumente --tls-cert-file und --tls-private-key-file entsprechend gesetzt sind (automatisiert).

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--tls-cert-file' ist vorhanden UND '--tls-private-key-file' ist vorhanden.

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Standardmäßig stellt K3s automatisch das TLS-Zertifikat und den privaten Schlüssel für den Kubelet bereit. Sie werden generiert und befinden sich unter /var/lib/rancher/k3s/agent/serving-kubelet.crt und /var/lib/rancher/k3s/agent/serving-kubelet.key. Wenn Sie aus irgendeinem Grund Ihr eigenes Zertifikat und Ihren eigenen Schlüssel bereitstellen müssen, können Sie die untenstehenden Parameter in der K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml setzen.

kubelet-arg:
  - "tls-cert-file=<path/to/tls-cert-file>"
  - "tls-private-key-file=<path/to/tls-private-key-file>"

4.2.10 Stellen Sie sicher, dass das Argument --rotate-certificates nicht auf false gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--rotate-certificates' ist vorhanden ODER '--rotate-certificates' ist nicht vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Standardmäßig setzt K3s das Argument --rotate-certificates nicht. Wenn Sie dieses Flag mit einem Wert von false gesetzt haben, sollten Sie es entweder auf true setzen oder das Flag vollständig entfernen. Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, entfernen Sie alle rotate-certificates-Parameter. Wenn Sie die Befehlszeile verwenden, entfernen Sie das K3s-Flag --kubelet-arg="rotate-certificates". Starten Sie den k3s-Dienst neu, basierend auf Ihrem System. Zum Beispiel: systemctl restart k3s.service

4.2.11 Überprüfen Sie, ob das Argument RotateKubeletServerCertificate auf true gesetzt ist (Automatisiert)

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: 'RotateKubeletServerCertificate' ist vorhanden ODER 'RotateKubeletServerCertificate' ist nicht vorhanden

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Standardmäßig setzt K3s das RotateKubeletServerCertificate Feature-Gate nicht. Wenn Sie dieses Feature-Gate aktiviert haben, sollten Sie es entfernen. Wenn Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, entfernen Sie jeden Parameter feature-gate=RotateKubeletServerCertificate. Wenn Sie die Befehlszeile verwenden, entfernen Sie das K3s-Flag --kubelet-arg="feature-gate=RotateKubeletServerCertificate". Starten Sie den k3s-Dienst neu, basierend auf Ihrem System. Zum Beispiel: systemctl restart k3s.service

4.2.12 Stellen Sie sicher, dass der Kubelet nur starke kryptografische Chiffren verwendet (Manuell)

Ergebnis: PASS

Revision:

journalctl -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1

Erwartetes Ergebnis: '--tls-cipher-suites' enthält gültige Elemente aus 'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256'

Zurückgegebener Wert: 
Aug 09 19:01:30 server-0 k3s[2354]: time="2024-08-09T19:01:30Z" level=info msg="Running kubelet --address=0.0.0.0 --allowed-unsafe-sysctls=net.ipv4.ip_forward,net.ipv6.conf.all.forwarding --anonymous-auth=false --authentication-token-webhook=true --authorization-mode=Webhook --cgroup-driver=systemd --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.crt --cloud-provider=external --cluster-dns=10.43.0.10 --cluster-domain=cluster.local --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --containerd=/run/k3s/containerd/containerd.sock --event-qps=0 --eviction-hard=imagefs.available<5%,nodefs.available<5% --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --fail-swap-on=false --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubelet.kubeconfig --make-iptables-util-chains=true --node-ip=10.10.10.100 --node-labels= --pod-infra-container-image=rancher/mirrored-pause:3.6 --pod-manifest-path=/var/lib/rancher/k3s/agent/pod-manifests --protect-kernel-defaults=true --read-only-port=0 --resolv-conf=/run/systemd/resolve/resolv.conf --serialize-image-pulls=false --streaming-connection-idle-timeout=5m --tls-cert-file=/var/lib/rancher/k3s/agent/serving-kubelet.crt --tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 --tls-private-key-file=/var/lib/rancher/k3s/agent/serving-kubelet.key"
Behebung:

Wenn Sie eine K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, bearbeiten Sie die Datei, um TLSCipherSuites auf

kubelet-arg:
  - "tls-cipher-suites=TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305"

oder auf eine Teilmenge dieser Werte zu setzen. Wenn Sie die Befehlszeile verwenden, fügen Sie das K3s-Flag --kubelet-arg="tls-cipher-suites=<same values as above>" hinzu. Starten Sie den k3s-Dienst neu, basierend auf Ihrem System. Zum Beispiel: systemctl restart k3s.service

4.2.13 Stellen Sie sicher, dass ein Limit für die Pod-PIDs festgelegt ist (Manuell)

Ergebnis: WARN

Behebung: Entscheiden Sie sich für ein angemessenes Niveau für diesen Parameter und setzen Sie es. Wenn Sie eine K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, bearbeiten Sie die Datei, um podPidsLimit auf

kubelet-arg:
  - "pod-max-pids=<value>"

5.1 RBAC und Dienstkonten

5.1.1 Stellen Sie sicher, dass die Rolle cluster-admin nur dort verwendet wird, wo es erforderlich ist (Manuell)

Ergebnis: WARN

Behebung: Identifizieren Sie alle clusterrolebindings zur Rolle cluster-admin. Überprüfen Sie, ob sie verwendet werden und ob sie diese Rolle benötigen oder ob sie eine Rolle mit weniger Berechtigungen verwenden könnten. Wo möglich, binden Sie zuerst Benutzer an eine Rolle mit geringeren Berechtigungen und entfernen Sie dann die ClusterRoleBinding zur Rolle cluster-admin: kubectl delete clusterrolebinding [name]

5.1.2 Minimieren Sie den Zugriff auf Geheimnisse (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf get, list und watch von Secret-Objekten im Cluster.

5.1.3 Minimieren Sie die Verwendung von Wildcards in Rollen und ClusterRoles (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, ersetzen Sie jede Verwendung von Wildcards in ClusterRoles und Rollen durch spezifische Objekte oder Aktionen.

5.1.4 Minimieren Sie den Zugriff auf das Erstellen von Pods (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf das Erstellen von Pod-Objekten im Cluster.

5.1.5 Stellen Sie sicher, dass Standarddienstkonten nicht aktiv verwendet werden. (Manuell)

Ergebnis: WARN

Behebung: Erstellen Sie explizite Dienstkonten, wo immer eine Kubernetes-Arbeitslast spezifischen Zugriff auf den Kubernetes-API-Server benötigt. Ändern Sie die Konfiguration jedes Standarddienstkontos, um diesen Wert aufzunehmen: automountServiceAccountToken: false

5.1.6 Stellen Sie sicher, dass Dienstkontotoken nur dort gemountet werden, wo es notwendig ist (Manuell)

Ergebnis: WARN

Behebung: Ändern Sie die Definition von Pods und Dienstkonten, die keine Dienstkontotoken mounten müssen, um dies zu deaktivieren.

5.1.7 Vermeiden Sie die Verwendung der Gruppe system:masters (Manuell)

Ergebnis: WARN

Behebung: Entfernen Sie die Gruppe system:masters von allen Benutzern im Cluster.

5.1.8 Begrenzen Sie die Verwendung der Berechtigungen Binden, Nachahmen und Eskalieren im Kubernetes-Cluster (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie die Rechte zum Nachahmen, Binden und Eskalieren von Subjekten.

5.1.9 Minimieren Sie den Zugriff auf das Erstellen von persistenten Volumes (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf das Erstellen von PersistentVolume-Objekten im Cluster.

5.1.10 Minimieren Sie den Zugriff auf die Proxy-Teilressource von Knoten (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf die Proxy-Teilressource von Knotenobjekten.

5.1.11 Minimieren Sie den Zugriff auf die Genehmigungs-Teilressource von Zertifikatsignierungsanforderungsobjekten (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf die Genehmigungs-Teilressource von Zertifikatsignierungsanforderungsobjekten.

5.1.12 Minimieren Sie den Zugriff auf Webhook-Konfigurationsobjekte (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf die validatingwebhookconfigurations- oder mutatingwebhookconfigurations-Objekte.

5.1.13 Minimieren Sie den Zugriff auf die Erstellung von Service-Account-Token (Manuell)

Ergebnis: WARN

Behebung: Wo möglich, entfernen Sie den Zugriff auf die Token-Teilressource von Service-Account-Objekten.

5.2 Pod-Sicherheitsstandards

5.2.1 Stellen Sie sicher, dass der Cluster mindestens einen aktiven Richtlinienkontrollmechanismus hat (Manuell)

Ergebnis: WARN

Behebung: Stellen Sie sicher, dass entweder Pod-Sicherheitszulassung oder ein externes Richtlinienkontrollsystem für jeden Namespace vorhanden ist, der Benutzerlasten enthält.

5.2.2 Minimieren Sie die Zulassung von privilegierten Containern (Manuell)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von privilegierten Containern einzuschränken.

5.2.3 Minimieren Sie die Zulassung von Containern, die den Host-Prozess-ID-Namespace teilen möchten (Automatisiert)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von hostPID Containern einzuschränken.

5.2.4 Minimieren Sie die Zulassung von Containern, die den Host-IPC-Namespace teilen möchten (Automatisiert)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von hostIPC Containern einzuschränken.

5.2.5 Minimieren Sie die Zulassung von Containern, die den Host-Netzwerk-Namespace teilen möchten (Automatisiert)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von hostNetwork Containern einzuschränken.

5.2.6 Minimieren Sie die Zulassung von Containern mit allowPrivilegeEscalation (Automatisiert)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von Containern mit .spec.allowPrivilegeEscalation auf true einzuschränken.

5.2.7 Minimieren Sie die Zulassung von Root-Containern (Automatisiert)

Ergebnis: WARN

Behebung: Erstellen Sie eine Richtlinie für jeden Namespace im Cluster, um sicherzustellen, dass entweder MustRunAsNonRoot oder MustRunAs mit dem Bereich der UIDs, der 0 nicht einschließt, festgelegt ist.

5.2.8 Minimieren Sie die Zulassung von Containern mit der NET_RAW-Fähigkeit (Automatisiert)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von Containern mit der NET_RAW-Fähigkeit einzuschränken.

5.2.9 Minimieren Sie die Zulassung von Containern mit hinzugefügten Fähigkeiten (Automatisiert)

Ergebnis: WARN

Behebung: Stellen Sie sicher, dass allowedCapabilities in den Richtlinien für den Cluster nicht vorhanden ist, es sei denn, es ist auf ein leeres Array gesetzt.

5.2.10 Minimieren Sie die Zulassung von Containern mit zugewiesenen Fähigkeiten (Manuell)

Ergebnis: WARN

Behebung: Überprüfen Sie die Verwendung von Fähigkeiten in Anwendungen, die auf Ihrem Cluster ausgeführt werden. Wenn ein Namespace Anwendungen enthält, die keine Linux-Fähigkeiten benötigen, um zu funktionieren, ziehen Sie in Betracht, eine PSP hinzuzufügen, die die Zulassung von Containern verbietet, die nicht alle Fähigkeiten ablegen.

5.2.11 Minimieren Sie die Zulassung von Windows HostProcess-Containern (Manuell)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von Containern einzuschränken, die .securityContext.windowsOptions.hostProcess auf true gesetzt haben.

5.2.12 Minimieren Sie die Zulassung von HostPath-Volumes (Manuell)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von Containern mit hostPath-Volumes einzuschränken.

5.2.13 Minimieren Sie die Zulassung von Containern, die HostPorts verwenden (Manuell)

Ergebnis: WARN

Behebung: Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von Containern einzuschränken, die hostPort-Abschnitte verwenden.

5.3 Netzwerk-Richtlinien und CNI

5.3.1 Stellen Sie sicher, dass das verwendete CNI Netzwerk-Richtlinien unterstützt (Manuell)

Ergebnis: WARN

Behebung: Wenn das verwendete CNI-Plugin keine Netzwerk-Richtlinien unterstützt, sollte in Betracht gezogen werden, ein anderes Plugin zu verwenden oder einen alternativen Mechanismus zur Einschränkung des Datenverkehrs im Kubernetes-Cluster zu finden.

5.3.2 Stellen Sie sicher, dass alle Namespaces Netzwerk-Richtlinien definiert haben (Manuell)

Ergebnis: WARN

Behebung: Befolgen Sie die Dokumentation und erstellen Sie Netzwerk-Richtlinienobjekte nach Bedarf.

5.4 Secretsverwaltung

5.4.1 Bevorzugen Sie die Verwendung von Secrets als Dateien gegenüber Secrets als Umgebungsvariablen (Manuell)

Ergebnis: WARN

Behebung: Falls möglich, schreiben Sie den Anwendungscode um, um Secrets aus gemounteten Secret-Dateien zu lesen, anstatt aus Umgebungsvariablen.

5.4.2 Ziehen Sie einen externen Secret-Speicher in Betracht (Manuell)

Ergebnis: WARN

Behebung: Verweisen Sie auf die von Ihrem Cloud-Anbieter oder einer Drittanbieter-Secretsverwaltungslösung angebotenen Optionen zur Secretsverwaltung.

5.5 Erweiterbare Zugangssteuerung

5.5.1 Konfigurieren Sie die Bildherkunft mithilfe des ImagePolicyWebhook Admission-Controllers (Manuell)

Ergebnis: WARN

Behebung: Befolgen Sie die Kubernetes-Dokumentation und richten Sie die Bild-Provenance ein.

5.7 Allgemeine Richtlinien

5.7.1 Erstellen Sie administrative Grenzen zwischen Ressourcen mithilfe von Namespaces (Manuell)

Ergebnis: WARN

Behebung: Befolgen Sie die Dokumentation und erstellen Sie Namespaces für Objekte in Ihrer Implementierung, wie Sie sie benötigen.

5.7.2 Stellen Sie sicher, dass das seccomp-Profil in Ihren Pod-Definitionen auf docker/default gesetzt ist (Manuell)

Ergebnis: WARN

Behebung: Verwenden Sie securityContext, um das docker/default seccomp-Profil in Ihren Pod-Definitionen zu aktivieren. Ein Beispiel ist wie folgt: securityContext: seccompProfile: type: RuntimeDefault

5.7.3 Wenden Sie SecurityContext auf Ihre Pods und Container an (Handbuch)

Ergebnis: WARN

Behebung: Befolgen Sie die Kubernetes-Dokumentation und wenden Sie SecurityContexts auf Ihre Pods an. Für eine vorgeschlagene Liste von SecurityContexts können Sie sich an den CIS-Sicherheitsbenchmark für Docker-Container wenden.

5.7.4 Der Standard-Namespace sollte nicht verwendet werden (Manuell)

Ergebnis: WARN

Behebung: Stellen Sie sicher, dass Namespaces erstellt werden, um eine angemessene Trennung der Kubernetes-Ressourcen zu ermöglichen, und dass alle neuen Ressourcen in einem bestimmten Namespace erstellt werden.