|
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.11 Leitfaden zur Selbstbewertung
Übersicht
Dieses Dokument ist ein Begleitdokument zum Sicherheitsleitfaden zur Härtung von K3s. 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.29-v1.34 Release-Reihe von K3s und die v1.11 Version des CIS Kubernetes Benchmark.
Weitere Informationen zu jeder Kontrolle, einschließlich detaillierter Beschreibungen und Maßnahmen zur Behebung fehlgeschlagener Tests, finden Sie im entsprechenden Abschnitt des CIS Kubernetes Benchmark v1.9. 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 Kontrollaudits vom ursprünglichen CIS-Benchmark abweichen, werden die spezifischen Audit-Befehle 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 es konzipiert ist, zu arbeiten. Der Abschnitt zur Behebung wird erklären, warum dies so ist.
-
Warn - 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-Unit ausgeführt wird. Ihre Installation kann abweichen und erfordert, dass Sie die Audit-Befehle an Ihr Szenario anpassen.
1.1 Konfigurationsdateien für Steuerungsknoten
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-Netzwerkschnittstelle-Datei auf 600 oder restriktiver gesetzt sind (Automatisiert)
Ergebnis: PASS
Revision:
find /var/lib/cni/networks -type f ! -name lock 2> /dev/null | xargs --no-run-if-empty stat -c permissions=%aErwartetes Ergebnis: Die Berechtigungen sollten 600 betragen bzw. restriktiver sein.
Zurückgegebener Wert:
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600
permissions=600Behebung:
Standardmäßig setzt K3s die CNI-Dateiberechtigungen auf 600.
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-Netzwerkschnittstelle-Datei auf root:root gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
find /var/lib/cni/networks -type f 2> /dev/null | xargs --no-run-if-empty stat -c %U:%GErwartetes Ergebnis: 'root:root' ist vorhanden
Zurückgegebener Wert:
root:root
root:root
root:root
root:root
root:root
root:root
root:rootBehebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf dem Steuerungsknoten aus.
Zum Beispiel, chown root:root /var/lib/cni/networks/<filename>
1.1.11 Stellen Sie sicher, dass die Berechtigungen des etcd-Verzeichnisses auf 700 oder restriktiver gesetzt sind (Manuell)
Ergebnis: PASS
Revision:
stat -c permissions=%a /var/lib/rancher/k3s/server/db/etcdErwartetes Ergebnis: Die Berechtigungen sollten 700 betragen bzw. restriktiver sein.
Zurückgegebener Wert:
permissions=700Behebung:
Nicht anwendbar für den Non-etcd-Cluster. Wenn nur der Master ohne etcd-Rolle ausgeführt wird, ist diese Überprüfung nicht anwendbar.
Wenn die Rollen Controlplane und etcd auf denselben Knoten vorhanden sind, jedoch diese Überprüfung nur als Warnhinweis gilt, dann ermitteln Sie auf dem etcd-Serverknoten das etcd-Datenverzeichnis, das als Argument --data-dir im 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-Verzeichnisses 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 Besitz des etcd-Verzeichnisses 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 eingestellt 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 Berechtigungen sollten 600 betragen bzw. restriktiver sein.
Zurückgegebener Wert:
permissions=600Behebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 eingestellt 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:rootBehebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 eingestellt 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: Die Berechtigungen sollten 600 betragen bzw. restriktiver sein.
Zurückgegebener Wert:
permissions=600Behebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 Eigentümer der Datei scheduler.conf 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:rootBehebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 eingestellt 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 betragen 600; es werden 600 oder restriktivere Berechtigungen erwartet.
Zurückgegebener Wert:
permissions=600Behebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 eingestellt ist (Automatisiert)
Ergebnis: PASS
Revision:
stat -c %U:%G /var/lib/rancher/k3s/server/cred/controller.kubeconfigErwartetes Ergebnis: 'root:root' ist gleich 'root:root'
Zurückgegebener Wert:
root:rootBehebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 die Dateien den Eigentümer root:root haben (Automatisiert)
Ergebnis: PASS
Revision:
stat -c %U:%G /var/lib/rancher/k3s/server/tlsErwartetes Ergebnis: 'root:root' ist vorhanden
Zurückgegebener Wert:
root:rootBehebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei 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 644 oder restriktiver eingestellt sind (Automatisiert)
Ergebnis: PASS
Revision:
/bin/sh -c 'stat -c permissions=%a /var/lib/rancher/k3s/server/tls/*.crt'Erwartetes Ergebnis: Die Berechtigungen betragen 644; es werden 644 oder restriktivere Berechtigungen erwartet.
Zurückgegebener Wert:
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644
permissions=644Behebung:
Führen Sie den folgenden Befehl (basierend auf dem Speicherort der Datei auf Ihrem System) auf dem Master-Knoten aus.
Zum Beispiel,
chmod -R 644 /var/lib/rancher/k3s/server/tls/*.crt
Standardmäßig setzt k3s die Berechtigungen der PKI-Zertifikatdateien auf 644, restriktivere Berechtigungen wie 600 werden unterstützt.
1.1.21 Stellen Sie sicher, dass die Berechtigungen der Kubernetes PKI-Schlüsseldatei auf 600 eingestellt sind (Automatisiert)
Ergebnis: PASS
Revision:
/bin/sh -c 'stat -c permissions=%a /var/lib/rancher/k3s/server/tls/*.key'Erwartetes Ergebnis: Die Berechtigungen betragen 600; es werden 600 oder restriktivere Berechtigungen erwartet.
Zurückgegebener Wert:
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=600Behebung:
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 eingestellt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'anonymous-auth'Erwartetes Ergebnis: '--anonymous-auth' ist gleich 'false'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alles, was ähnlich ist wie unten.
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 -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--token-auth-file' ist nicht vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 ähnlich ist wie unten.
kube-apiserver-arg: - "token-auth-file=<path>"
1.2.3 Stellen Sie sicher, dass --DenyServiceExternalIPs gesetzt ist (Manuell)
Ergebnis: WARN
Behebung: Standardmäßig setzt K3s DenyServiceExternalIPs nicht. Um dieses Flag zu aktivieren, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml wie unten gezeigt.
kube-apiserver-arg: - "enable-admission-plugins=DenyServiceExternalIPs"
1.2.4 Stellen Sie sicher, dass die Argumente --kubelet-client-certificate und --kubelet-client-key entsprechend gesetzt sind (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--kubelet-client-certificate' ist vorhanden UND '--kubelet-client-key' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 Argument --kubelet-certificate-authority entsprechend gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'kubelet-certificate-authority'Erwartetes Ergebnis: '--kubelet-certificate-authority' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 Sie aus irgendeinem Grund Ihr eigenes CA-Zertifikat bereitstellen müssen, sollten Sie das k3s-Zertifikat-Kommandozeilenwerkzeug verwenden. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten gezeigt.
kube-apiserver-arg: - "kubelet-certificate-authority=<path/to/ca-cert-file>"
1.2.6 Stellen Sie sicher, dass das Argument --authorization-mode nicht auf AlwaysAllow gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'Erwartetes Ergebnis: '--authorization-mode' enthält nicht 'AlwaysAllow'.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 gezeigt.
kube-apiserver-arg: - "authorization-mode=AlwaysAllow"
1.2.7 Stellen Sie sicher, dass das Argument --authorization-mode Node enthält (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'Erwartetes Ergebnis: '--authorization-mode' hat 'Node'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 Argument --authorization-mode den Wert 'RBAC' enthält (automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'authorization-mode'Erwartetes Ergebnis: '--authorization-mode' hat 'RBAC'.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'Erwartetes Ergebnis: '--enable-admission-plugins' enthält nicht 'AlwaysAdmit' oder '--enable-admission-plugins' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 --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 gezeigt.
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 vorab geladene Images haben und keinen Zugriff auf eine Registry haben, um verwendete Images 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 ServiceAccount gesetzt ist (automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--disable-admission-plugins' ist vorhanden ODER '--disable-admission-plugins' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 --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 gezeigt.
kube-apiserver-arg: - "disable-admission-plugins=ServiceAccount"
1.2.13 Stellen Sie sicher, dass das Admission-Control-Plugin NamespaceLifecycle gesetzt ist (automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--disable-admission-plugins' ist vorhanden ODER '--disable-admission-plugins' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 --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 gezeigt.
kube-apiserver-arg: - "disable-admission-plugins=...,NamespaceLifecycle,..."
1.2.14 Stellen Sie sicher, dass das Admission-Control-Plugin NodeRestriction gesetzt ist (automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'enable-admission-plugins'Erwartetes Ergebnis: '--enable-admission-plugins' enthält 'NodeRestriction'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 ja, fügen Sie NodeRestriction in die Liste ein.
kube-apiserver-arg: - "enable-admission-plugins=...,NodeRestriction,..."
1.2.15 Stellen Sie sicher, dass das --profiling-Argument auf false gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'profiling'Erwartetes Ergebnis: '--profiling' ist gleich 'false'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 gezeigt.
kube-apiserver-arg: - "profiling=true"
1.2.16 Stellen Sie sicher, dass das --audit-log-path-Argument gesetzt ist (Manuell)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--audit-log-path' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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.17 Stellen Sie sicher, dass das --audit-log-maxage-Argument auf 30 oder entsprechend gesetzt ist (Manuell)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--audit-log-maxage' ist größer oder gleich 30
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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.18 Stellen Sie sicher, dass das --audit-log-maxbackup-Argument auf 10 oder entsprechend gesetzt ist (Manuell)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--audit-log-maxbackup' ist größer oder gleich 10
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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.19 Stellen Sie sicher, dass das --audit-log-maxsize-Argument auf 100 oder entsprechend gesetzt ist (Manuell)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--audit-log-maxsize' ist größer oder gleich 100
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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.20 Stellen Sie sicher, dass das --request-timeout-Argument entsprechend gesetzt 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.21 Stellen Sie sicher, dass das --service-account-lookup-Argument auf true gesetzt ist (automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--service-account-lookup' ist nicht vorhanden ODER '--service-account-lookup' ist vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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-Argument. Beispiel:
kube-apiserver-arg: - "service-account-lookup=true"
Alternativ können Sie den Parameter service-account-lookup aus dieser Datei löschen, damit das Standardverhalten wirksam wird.
1.2.22 Stellen Sie sicher, dass das --service-account-key-file-Argument entsprechend festgelegt ist (automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1Erwartetes Ergebnis: '--service-account-key-file' ist vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 Schlüsseldatei für das Service-Konto. 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 die folgende.
kube-apiserver-arg: - "service-account-key-file=<path>"
1.2.23 Stellen Sie sicher, dass die Argumente --etcd-certfile und --etcd-keyfile entsprechend festgelegt sind (automatisiert).
Ergebnis: PASS
Revision:
if [ "$(journalctl -m -u k3s | grep -m1 'Managed etcd cluster' | wc -l)" -gt 0 ]; then
journalctl -m -u k3s | grep -m1 'Running kube-apiserver' | tail -n1
else
echo "--etcd-certfile AND --etcd-keyfile"
fiErwartetes Ergebnis: '--etcd-certfile' ist vorhanden UND '--etcd-keyfile' ist vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 gezeigt.
kube-apiserver-arg: - "etcd-certfile=<path>" - "etcd-keyfile=<path>"
1.2.24 Stellen Sie sicher, dass die Argumente --tls-cert-file und --tls-private-key-file entsprechend festgelegt sind (automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep -A1 'Running kube-apiserver' | tail -n2Erwartetes Ergebnis: '--tls-cert-file' ist vorhanden UND '--tls-private-key-file' ist vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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"
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-scheduler/kube-scheduler.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-scheduler/kube-scheduler.key"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 die folgende.
kube-apiserver-arg: - "tls-cert-file=<path>" - "tls-private-key-file=<path>"
1.2.25 Stellen Sie sicher, dass das --client-ca-file-Argument entsprechend gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'client-ca-file'Erwartetes Ergebnis: '--client-ca-file' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 Client-Zertifizierungsstellen-Datei zur Verfügung. Sie wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/client-ca.crt. Wenn Sie aus irgendeinem Grund Ihr eigenes CA-Zertifikat bereitstellen müssen, sollten Sie das k3s-Zertifikat-Kommandozeilenwerkzeug verwenden. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten gezeigt.
kube-apiserver-arg: - "client-ca-file=<path>"
1.2.26 Stellen Sie sicher, dass das --etcd-cafile-Argument entsprechend gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'etcd-cafile'Erwartetes Ergebnis: '--etcd-cafile' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 etcd-Zertifizierungsstellen-Datei zur Verfügung. Sie wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/client-ca.crt. Wenn Sie aus irgendeinem Grund Ihr eigenes CA-Zertifikat bereitstellen müssen, sollten Sie das k3s-Zertifikat-Kommandozeilenwerkzeug verwenden. Wenn diese Überprüfung fehlschlägt, bearbeiten Sie die K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml und entfernen Sie alle Zeilen wie unten gezeigt.
kube-apiserver-arg: - "etcd-cafile=<path>"
1.2.27 Stellen Sie sicher, dass das Argument --encryption-provider-config entsprechend gesetzt ist (Manuell)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'encryption-provider-config'Erwartetes Ergebnis: '--encryption-provider-config' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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-Kommandozeilenwerkzeug secrets-encrypt verwaltet werden. Falls erforderlich, finden Sie die generierte Verschlüsselungskonfiguration unter /var/lib/rancher/k3s/server/cred/encryption-config.json.
1.2.28 Stellen Sie sicher, dass die Verschlüsselungsanbieter angemessen konfiguriert sind (Manuell)
Ergebnis: PASS
Revision:
ENCRYPTION_PROVIDER_CONFIG=$(journalctl -m -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=/'; fiErwartetes Ergebnis: 'provider' enthält gültige Elemente aus 'aescbc,kms,secretbox'
Zurückgegebener Wert:
provider=aescbcBehebung:
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-Kommandozeilenwerkzeug secrets-encrypt verwaltet werden. Falls erforderlich, finden Sie die generierte Verschlüsselungskonfiguration unter /var/lib/rancher/k3s/server/cred/encryption-config.json
1.2.29 Stellen Sie sicher, dass der API-Server nur starke kryptografische Chiffren verwendet (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -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_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_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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, sollten Sie auch in Betracht ziehen, eine benutzerdefinierte Version dieser Regel zu erstellen, die Ihren Anforderungen entspricht.
Wenn diese Überprüfung fehlschlägt, entfernen Sie alle benutzerdefinierten Konfigurationen rund um tls-cipher-suites oder aktualisieren Sie die Datei /etc/rancher/k3s/config.yaml, um die Standardeinstellungen anzupassen, 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.2.30 Stellen Sie sicher, dass der Parameter --service-account-extend-token-expiration auf false gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s | grep 'Running kube-apiserver' | tail -n1 | grep 'service-account-extend-token-expiration'Erwartetes Ergebnis: '--service-account-extend-token-expiration' ist gleich 'false'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 --service-account-extend-token-expiration auf false, bevor Sie k3s neu laden, wie folgt: kube-apiserver-arg: - "service-account-extend-token-expiration=false" Standardmäßig ist dieser Parameter auf true gesetzt.
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 -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --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 -m -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'profiling'Erwartetes Ergebnis: '--profiling' ist gleich 'false'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --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 gezeigt.
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 -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --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 gezeigt.
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 -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --use-service-account-credentials=true"Behebung:
Standardmäßig stellt K3s automatisch die private Schlüsseldatei des Dienstkontos zur Verfügung. Es 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 -m -u k3s | grep 'Running kube-controller-manager' | tail -n1 | grep 'root-ca-file'Erwartetes Ergebnis: '--root-ca-file' ist vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --use-service-account-credentials=true"Behebung:
Standardmäßig stellt K3s automatisch die Root-CA-Datei bereit. Es wird generiert und befindet sich unter /var/lib/rancher/k3s/server/tls/server-ca.crt. Wenn Sie aus irgendeinem Grund Ihr eigenes CA-Zertifikat bereitstellen müssen, sollten Sie das K3s-Zertifikat-Kommandozeilenwerkzeug verwenden. 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 -m -u k3s | grep 'Running kube-controller-manager' | tail -n1Erwartetes Ergebnis: '--feature-gates' ist vorhanden ODER '--feature-gates' ist nicht vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --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:
journalctl -m -u k3s | grep 'Running kube-controller-manager' | tail -n1Erwartetes Ergebnis: '--bind-address' ist gleich '127.0.0.1' ODER '--bind-address' ist nicht vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-controller-manager/kube-controller-manager.key --use-service-account-credentials=true"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 -m -u k3s | grep 'Running kube-scheduler' | tail -n1 | grep 'profiling'Erwartetes Ergebnis: '--profiling' ist gleich 'false'
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-scheduler/kube-scheduler.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-scheduler/kube-scheduler.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-scheduler-arg: - "profiling=true"
1.4.2 Stellen Sie sicher, dass das --bind-address-Argument auf 127.0.0.1 (Automatisiert) gesetzt ist.
Ergebnis: PASS
Revision:
journalctl -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --tls-cert-file=/var/lib/rancher/k3s/server/tls/kube-scheduler/kube-scheduler.crt --tls-private-key-file=/var/lib/rancher/k3s/server/tls/kube-scheduler/kube-scheduler.key"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 (Manuell).
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprü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 --client-cert-auth-Argument auf true (Manuell) gesetzt ist.
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd setzt K3s den --client-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 mit Client-Zertifikaten zu deaktivieren.
2.3 Stellen Sie sicher, dass das --auto-tls-Argument nicht auf true (Manuell) gesetzt ist.
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprüfungen nicht anwendbar. Beim Betrieb mit embedded-etcd setzt K3s den --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 --auto-tls-Parameter 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 (Manuell).
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprü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-Zertifikate und Schlüsseldateien zu verwenden.
2.5 Stellen Sie sicher, dass das --peer-client-cert-auth-Argument auf true gesetzt ist (Manuell)
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprü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 (Manuell)
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprüfungen nicht anwendbar. 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 CA für etcd verwendet wird (Manuell)
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
experimental-watch-progress-notify-interval: 5000000000
heartbeat-interval: 500
initial-advertise-peer-urls: https://10.10.10.100:2380
initial-cluster: server-0-82b8dedf=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-82b8dedf
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
socket-options:
reuse-address: true
reuse-port: trueBehebung:
Wenn Sie mit sqlite oder einer externen DB arbeiten, sind etcd-Überprü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.
All configuration is passed in as arguments at container run time.
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: Die Berechtigungen betragen 600 bzw. sind restriktiver
Zurückgegebener Wert:
permissions=600Behebung:
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:rootBehebung:
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: Die Berechtigungen betragen 600 bzw. sind restriktiver
Zurückgegebener Wert:
permissions=600Behebung:
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 die --kubeconfig kubelet.conf-Dateieigentümerschaft auf root:root gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
stat -c %U:%G /var/lib/rancher/k3s/agent/kubelet.kubeconfigErwartetes Ergebnis: 'root:root' ist vorhanden
Zurückgegebener Wert:
root:rootBehebung:
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/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.crtErwartetes Ergebnis: Die Berechtigungen sind 600, erwartet werden 600 oder restriktiver
Zurückgegebener Wert:
permissions=600Behebung:
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.crtErwartetes Ergebnis: 'root:root' ist gleich 'root:root'
Zurückgegebener Wert:
root:rootBehebung:
Führen Sie den folgenden Befehl aus, um die Eigentümerschaft 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:
Der 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:
Der 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 -m -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 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 Kommandozeilenschnittstelle 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 -m -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 -m -u k3s | grep "Running kube-apiserver" | wc -l) -gt 0; then journalctl -m -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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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 --encryption-provider-config-automatic-reload=true --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 --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-extend-token-expiration=false --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 den Kubelet bereit. Es wird generiert und befindet sich unter /var/lib/rancher/k3s/agent/client-ca.crt.
4.2.4 Überprüfen Sie, ob das --read-only-port-Argument, falls definiert, auf 0 gesetzt ist (Automatisiert).
Ergebnis: PASS
Revision:
journalctl -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: '--read-only-port' ist gleich '0' ODER '--read-only-port' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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 -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: '--streaming-connection-idle-timeout' ist nicht gleich '0' ODER '--streaming-connection-idle-timeout' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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. Je nach System starten Sie den k3s-Dienst 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 -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: '--make-iptables-util-chains' ist gleich 'true' ODER '--make-iptables-util-chains' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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. Je nach System starten Sie den k3s-Dienst 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 -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: '--event-qps' ist größer oder gleich 0 ODER '--event-qps' ist nicht vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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. Je nach System starten Sie den k3s-Dienst 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 -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: '--tls-cert-file' ist vorhanden UND '--tls-private-key-file' ist vorhanden.
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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 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 --rotate-certificates Argument nicht auf false gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: '--rotate-certificates' ist vorhanden ODER '--rotate-certificates' ist nicht vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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 --rotate-certificates Argument 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 jeden rotate-certificates Parameter.
Wenn Sie die Befehlszeile verwenden, entfernen Sie das K3s-Flag --kubelet-arg="rotate-certificates".
Starten Sie den k3s-Dienst basierend auf Ihrem System neu. Zum Beispiel:
systemctl restart k3s.service
4.2.11 Überprüfen Sie, ob das RotateKubeletServerCertificate Argument auf true gesetzt ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes Ergebnis: 'RotateKubeletServerCertificate' ist vorhanden ODER 'RotateKubeletServerCertificate' ist nicht vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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 feature-gate=RotateKubeletServerCertificate Parameter. Wenn Sie die Befehlszeile verwenden, entfernen Sie das K3s-Flag --kubelet-arg="feature-gate=RotateKubeletServerCertificate". Starten Sie den k3s-Dienst basierend auf Ihrem System neu. Zum Beispiel: systemctl restart k3s.service
4.2.12 Stellen Sie sicher, dass Kubelet nur starke kryptografische Chiffren verwendet (Manuell)
Ergebnis: PASS
Revision:
journalctl -m -u k3s -u k3s-agent | grep 'Running kubelet' | tail -n1Erwartetes 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:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" 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-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. Wenn Sie die Befehlszeile verwenden, fügen Sie das K3s-Flag --kubelet-arg="tls-cipher-suites=<die gleichen Werte wie oben>" hinzu. Basierend auf Ihrem System, starten Sie den k3s-Dienst neu. 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>"
4.2.14 Stellen Sie sicher, dass der --seccomp-default Parameter auf true gesetzt ist (Manuell)
Ergebnis: WARN
Behebung:
Wenn aktiviert, verwendet das Kubelet standardmäßig das RuntimeDefault seccomp-Profil, das von der Container-Laufzeit definiert wird, anstatt den Unconfined (seccomp deaktiviert) Modus (Standard) zu verwenden.
Wenn Sie eine K3s-Konfigurationsdatei /etc/rancher/k3s/config.yaml verwenden, bearbeiten Sie die Datei, um seccomp-default auf kubelet-arg: - "seccomp-default=true" zu setzen.
4.3 kube-proxy
4.3.1 Stellen Sie sicher, dass der kube-proxy-Metrikdienst an localhost gebunden ist (Automatisiert)
Ergebnis: PASS
Revision:
journalctl -m -u k3s -u k3s-agent | grep 'Running kube-proxy' | tail -n1Erwartetes Ergebnis: '--metrics-bind-address' ist vorhanden ODER '--metrics-bind-address' ist nicht vorhanden
Zurückgegebener Wert:
Sep 16 15:47:27 server-0 k3s[2233]: time="2025-09-16T15:47:27Z" level=info msg="Running kube-proxy --cluster-cidr=10.42.0.0/16 --conntrack-max-per-core=0 --conntrack-tcp-timeout-close-wait=0s --conntrack-tcp-timeout-established=0s --healthz-bind-address=127.0.0.1 --hostname-override=server-0 --kubeconfig=/var/lib/rancher/k3s/agent/kubeproxy.kubeconfig --proxy-mode=iptables"Behebung:
Ändern oder entfernen Sie alle Werte, die den Metrikdienst an eine Nicht-localhost-Adresse binden. Der Standardwert ist 127.0.0.1:10249.
5.1 RBAC und Dienstkonten
5.1.1 Stellen Sie sicher, dass die Rolle des Cluster-Administrators nur dort verwendet wird, wo es erforderlich ist (Manuell)
Ergebnis: PASS
Revision:
kubectl get clusterrolebindings -o=custom-columns=ROLE:.roleRef.name,NAME:.metadata.name,SUBJECT:.subjects[*].name --no-headers | grep cluster-adminErwartetes Ergebnis: 'cluster-admin' enthält gültige Elemente aus 'cluster-admin, helm-kube-system-traefik, helm-kube-system-traefik-crd'
Zurückgegebener Wert:
cluster-admin cluster-admin system:masters
cluster-admin helm-kube-system-traefik helm-traefik
cluster-admin helm-kube-system-traefik-crd helm-traefik-crdBehebung:
Identifizieren Sie alle Clusterrolebindings zur Rolle des Cluster-Administrators. Überprüfen Sie, ob sie verwendet werden und ob sie diese Rolle benötigen oder ob sie eine Rolle mit weniger Rechten verwenden könnten. K3s gibt Ausnahmen für die Clusterrolebindings helm-kube-system-traefik und helm-kube-system-traefik-crd, da diese für die Installation von traefik im kube-system-Namespace für den regulären Betrieb erforderlich sind. Wo möglich, binden Sie zuerst Benutzer an eine weniger privilegierte Rolle und entfernen Sie dann das Clusterrolebinding zur Rolle des Cluster-Administrators:
kubectl delete clusterrolebinding [name]
5.1.2 Minimieren Sie den Zugriff auf Geheimnisse (Manuell)
Ergebnis: PASS
Revision:
echo "canGetListWatchSecretsAsSystemAuthenticated: $(kubectl auth can-i get,list,watch secrets --all-namespaces --as=system:authenticated)"Erwartetes Ergebnis: 'canGetListWatchSecretsAsSystemAuthenticated' ist gleich 'nein'
Zurückgegebener Wert:
canGetListWatchSecretsAsSystemAuthenticated: noBehebung:
Wo möglich, entfernen Sie den Zugriff auf get, list und watch auf Secret-Objekte im Cluster.
5.1.3 Minimieren Sie die Verwendung von Wildcards in Rollen und ClusterRoles (Manuell)
Ergebnis: PASS
Revision:
# Check Roles
kubectl get roles --all-namespaces -o custom-columns=ROLE_NAMESPACE:.metadata.namespace,ROLE_NAME:.metadata.name --no-headers | while read -r role_namespace role_name
do
role_rules=$(kubectl get role -n "${role_namespace}" "${role_name}" -o=json | jq -c '.rules')
if echo "${role_rules}" | grep -q "\[\"\*\"\]"; then
printf "**role_name: %-50s role_namespace: %-25s role_rules: %s is_compliant: false\n" "${role_name}" "${role_namespace}" "${role_rules}"
else
printf "**role_name: %-50s role_namespace: %-25s is_compliant: true\n" "${role_name}" "${role_namespace}"
fi;
done
cr_whitelist="cluster-admin k3s-cloud-controller-manager local-path-provisioner-role"
cr_whitelist="$cr_whitelist system:kube-controller-manager system:kubelet-api-admin system:controller:namespace-controller"
cr_whitelist="$cr_whitelist system:controller:disruption-controller system:controller:generic-garbage-collector"
cr_whitelist="$cr_whitelist system:controller:horizontal-pod-autoscaler system:controller:resourcequota-controller"
# Check ClusterRoles
kubectl get clusterroles -o custom-columns=CLUSTERROLE_NAME:.metadata.name --no-headers | while read -r clusterrole_name
do
clusterrole_rules=$(kubectl get clusterrole "${clusterrole_name}" -o=json | jq -c '.rules')
if echo "${cr_whitelist}" | grep -q "${clusterrole_name}"; then
printf "**clusterrole_name: %-50s is_whitelist: true is_compliant: true\n" "${clusterrole_name}"
elif echo "${clusterrole_rules}" | grep -q "\[\"\*\"\]"; then
echo "**clusterrole_name: ${clusterrole_name} clusterrole_rules: ${clusterrole_rules} is_compliant: false"
else
printf "**clusterrole_name: %-50s is_whitelist: false is_compliant: true\n" "${clusterrole_name}"
fi;
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true'
Rückgabewert:
**role_name: system:controller:bootstrap-signer role_namespace: kube-public is_compliant: true
**role_name: extension-apiserver-authentication-reader role_namespace: kube-system is_compliant: true
**role_name: system::leader-locking-kube-controller-manager role_namespace: kube-system is_compliant: true
**role_name: system::leader-locking-kube-scheduler role_namespace: kube-system is_compliant: true
**role_name: system:controller:bootstrap-signer role_namespace: kube-system is_compliant: true
**role_name: system:controller:cloud-provider role_namespace: kube-system is_compliant: true
**role_name: system:controller:token-cleaner role_namespace: kube-system is_compliant: true
**clusterrole_name: admin is_whitelist: true is_compliant: true
**clusterrole_name: cluster-admin is_whitelist: true is_compliant: true
**clusterrole_name: clustercidrs-node is_whitelist: false is_compliant: true
**clusterrole_name: edit is_whitelist: false is_compliant: true
**clusterrole_name: k3s-cloud-controller-manager is_whitelist: true is_compliant: true
**clusterrole_name: local-path-provisioner-role is_whitelist: true is_compliant: true
**clusterrole_name: system:aggregate-to-admin is_whitelist: false is_compliant: true
**clusterrole_name: system:aggregate-to-edit is_whitelist: false is_compliant: true
**clusterrole_name: system:aggregate-to-view is_whitelist: false is_compliant: true
**clusterrole_name: system:aggregated-metrics-reader is_whitelist: false is_compliant: true
**clusterrole_name: system:auth-delegator is_whitelist: false is_compliant: true
**clusterrole_name: system:basic-user is_whitelist: false is_compliant: true
**clusterrole_name: system:certificates.k8s.io:certificatesigningrequests:nodeclient is_whitelist: false is_compliant: true
**clusterrole_name: system:certificates.k8s.io:certificatesigningrequests:selfnodeclient is_whitelist: false is_compliant: true
**clusterrole_name: system:certificates.k8s.io:kube-apiserver-client-approver is_whitelist: false is_compliant: true
**clusterrole_name: system:certificates.k8s.io:kube-apiserver-client-kubelet-approver is_whitelist: false is_compliant: true
**clusterrole_name: system:certificates.k8s.io:kubelet-serving-approver is_whitelist: false is_compliant: true
**clusterrole_name: system:certificates.k8s.io:legacy-unknown-approver is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:attachdetach-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:certificate-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:clusterrole-aggregation-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:cronjob-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:daemon-set-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:deployment-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:disruption-controller is_whitelist: true is_compliant: true
**clusterrole_name: system:controller:endpoint-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:endpointslice-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:endpointslicemirroring-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:ephemeral-volume-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:expand-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:generic-garbage-collector is_whitelist: true is_compliant: true
**clusterrole_name: system:controller:horizontal-pod-autoscaler is_whitelist: true is_compliant: true
**clusterrole_name: system:controller:job-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:legacy-service-account-token-cleaner is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:namespace-controller is_whitelist: true is_compliant: true
**clusterrole_name: system:controller:node-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:persistent-volume-binder is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:pod-garbage-collector is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:pv-protection-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:pvc-protection-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:replicaset-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:replication-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:resourcequota-controller is_whitelist: true is_compliant: true
**clusterrole_name: system:controller:root-ca-cert-publisher is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:route-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:service-account-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:service-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:statefulset-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:ttl-after-finished-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:ttl-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:controller:validatingadmissionpolicy-status-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:coredns is_whitelist: false is_compliant: true
**clusterrole_name: system:discovery is_whitelist: false is_compliant: true
**clusterrole_name: system:heapster is_whitelist: false is_compliant: true
**clusterrole_name: system:k3s-controller is_whitelist: false is_compliant: true
**clusterrole_name: system:kube-aggregator is_whitelist: false is_compliant: true
**clusterrole_name: system:kube-controller-manager is_whitelist: true is_compliant: true
**clusterrole_name: system:kube-dns is_whitelist: false is_compliant: true
**clusterrole_name: system:kube-scheduler is_whitelist: false is_compliant: true
**clusterrole_name: system:kubelet-api-admin is_whitelist: true is_compliant: true
**clusterrole_name: system:metrics-server is_whitelist: false is_compliant: true
**clusterrole_name: system:monitoring is_whitelist: false is_compliant: true
**clusterrole_name: system:node is_whitelist: false is_compliant: true
**clusterrole_name: system:node-bootstrapper is_whitelist: false is_compliant: true
**clusterrole_name: system:node-problem-detector is_whitelist: false is_compliant: true
**clusterrole_name: system:node-proxier is_whitelist: false is_compliant: true
**clusterrole_name: system:persistent-volume-provisioner is_whitelist: false is_compliant: true
**clusterrole_name: system:public-info-viewer is_whitelist: false is_compliant: true
**clusterrole_name: system:service-account-issuer-discovery is_whitelist: false is_compliant: true
**clusterrole_name: system:volume-scheduler is_whitelist: false is_compliant: true
**clusterrole_name: traefik-kube-system is_whitelist: false is_compliant: true
**clusterrole_name: view is_whitelist: false is_compliant: trueBehebung:
Wo möglich, ersetzen Sie jede Verwendung von Wildcards in ClusterRoles und Roles durch spezifische Objekte oder Aktionen. K3s gibt Ausnahmen für folgende Clusterrollen, die für den regulären Betrieb erforderlich sind: - k3s-cloud-controller-manager, local-path-provisioner-role, cluster-admin - system:kube-controller-manager, system:kubelet-api-admin, system:controller:namespace-controller, - system:controller:disruption-controller, system:controller:generic-garbage-collector, - system:controller:horizontal-pod-autoscaler, system:controller:resourcequota-controller
5.1.4 Minimieren Sie den Zugriff auf das Erstellen von Pods (Manuell)
Ergebnis: PASS
Revision:
echo "canCreatePodsAsSystemAuthenticated: $(kubectl auth can-i create pods --all-namespaces --as=system:authenticated)"Erwartetes Ergebnis: 'canCreatePodsAsSystemAuthenticated' ist gleich 'nein'
Rückgabewert:
canCreatePodsAsSystemAuthenticated: noBehebung:
Wo möglich, entfernen Sie den Erstellungszugriff auf Pod-Objekte 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. K3s macht eine Ausnahme für das Standarddienstkonto im kube-system-Namespace. Ändern Sie die Konfiguration jedes Standarddienstkontos, sodass der Wert automountServiceAccountToken: false enthalten ist. Alternativ verwenden Sie kubectl:
kubectl patch serviceaccount --namespace <NAMESPACE> default --patch '{"automountServiceAccountToken": false}'5.1.6 Stellen Sie sicher, dass Dienstkonto-Token nur dort gemountet werden, wo es notwendig ist (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAMESPACE:.metadata.namespace,POD_NAME:.metadata.name,POD_SERVICE_ACCOUNT:.spec.serviceAccount,POD_IS_AUTOMOUNTSERVICEACCOUNTTOKEN:.spec.automountServiceAccountToken --no-headers | while read -r pod_namespace pod_name pod_service_account pod_is_automountserviceaccounttoken
do
# Retrieve automountServiceAccountToken's value for ServiceAccount and Pod, set to notset if null or <none>.
svacc_is_automountserviceaccounttoken=$(kubectl get serviceaccount -n "${pod_namespace}" "${pod_service_account}" -o json | jq -r '.automountServiceAccountToken' | sed -e 's/<none>/notset/g' -e 's/null/notset/g')
pod_is_automountserviceaccounttoken=$(echo "${pod_is_automountserviceaccounttoken}" | sed -e 's/<none>/notset/g' -e 's/null/notset/g')
if [ "${svacc_is_automountserviceaccounttoken}" = "false" ] && ( [ "${pod_is_automountserviceaccounttoken}" = "false" ] || [ "${pod_is_automountserviceaccounttoken}" = "notset" ] ); then
is_compliant="true"
elif [ "${svacc_is_automountserviceaccounttoken}" = "true" ] && [ "${pod_is_automountserviceaccounttoken}" = "false" ]; then
is_compliant="true"
else
is_compliant="false"
fi
echo "**namespace: ${pod_namespace} pod_name: ${pod_name} service_account: ${pod_service_account} pod_is_automountserviceaccounttoken: ${pod_is_automountserviceaccounttoken} svacc_is_automountServiceAccountToken: ${svacc_is_automountserviceaccounttoken} is_compliant: ${is_compliant}"
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true' ODER 'service_account' enthält gültige Elemente von 'coredns, helm-traefik, helm-traefik-crd, traefik, metrics-server, svclb, local-path-provisioner-service-account'
Zurückgegebener Wert:
**namespace: kube-system pod_name: coredns-645bdb8675-sm78l service_account: coredns pod_is_automountserviceaccounttoken: notset svacc_is_automountServiceAccountToken: notset is_compliant: false
**namespace: kube-system pod_name: helm-install-traefik-4qhld service_account: helm-traefik pod_is_automountserviceaccounttoken: notset svacc_is_automountServiceAccountToken: true is_compliant: false
**namespace: kube-system pod_name: helm-install-traefik-crd-dqkpt service_account: helm-traefik-crd pod_is_automountserviceaccounttoken: notset svacc_is_automountServiceAccountToken: true is_compliant: false
**namespace: kube-system pod_name: local-path-provisioner-ffbcc4db4-pzhw4 service_account: local-path-provisioner-service-account pod_is_automountserviceaccounttoken: notset svacc_is_automountServiceAccountToken: notset is_compliant: false
**namespace: kube-system pod_name: metrics-server-8677f8544d-kg66f service_account: metrics-server pod_is_automountserviceaccounttoken: notset svacc_is_automountServiceAccountToken: notset is_compliant: false
**namespace: kube-system pod_name: svclb-traefik-01b74a90-k47w2 service_account: svclb pod_is_automountserviceaccounttoken: false svacc_is_automountServiceAccountToken: notset is_compliant: false
**namespace: kube-system pod_name: traefik-5b6d9f7f5c-rs5sw service_account: traefik pod_is_automountserviceaccounttoken: notset svacc_is_automountServiceAccountToken: notset is_compliant: falseBehebung:
Ändern Sie die Definition von Dienstkonten und Pods, die keine Dienstkonto-Token mounten müssen, um dies mit automountServiceAccountToken: false zu deaktivieren.
Wenn sowohl das Dienstkonto als auch die .spec des Pods einen Wert für automountServiceAccountToken angeben, hat die Pod-Spezifikation Vorrang.
Bedingung: Pod ist_compliant, wenn:
- das Dienstkonto automountServiceAccountToken auf false gesetzt ist und der Pod automountServiceAccountToken entweder auf false oder nicht gesetzt ist;
- das Dienstkonto automountServiceAccountToken auf true (bzw. nicht gesetzt) ist und der Pod automountServiceAccountToken auf false gesetzt ist.
K3s gewährt Ausnahmen für die folgenden Dienstkonten, die für den regulären Betrieb erforderlich sind:
– coredns, helm-traefik, helm-traefik-crd, traefik, metrics-server, svclb, local-path-provisioner-service-account
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 Bind, Impersonate und Escalate im Kubernetes-Cluster (Manuell)
Ergebnis: WARN
Behebung: Wo möglich, entfernen Sie die Rechte Impersonate, Bind und Escalate von Subjekten.
5.1.9 Minimieren Sie den Zugriff auf die Erstellung von persistenten Volumes (Manuell)
Ergebnis: WARN
Behebung: Wo möglich, entfernen Sie den Erstellungszugriff auf PersistentVolume-Objekte 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 Den Zugriff auf die Genehmigungs-Teilressource von Zertifikatsanfragenobjekten minimieren (Manuell)
Ergebnis: WARN
Behebung: Wo möglich, entfernen Sie den Zugriff auf die Genehmigungs-Teilressource von Zertifikatsanfragenobjekten.
5.2 Pod-Sicherheitsstandards
Stellen Sie sicher, dass der Cluster mindestens einen aktiven Richtlinienkontrollmechanismus aufweist (Manuell).
Ergebnis: WARN
Behebung: Stellen Sie sicher, dass entweder die Pod-Sicherheitszulassung oder ein externes Richtlinienkontrollsystem in jedem Namespace, der Benutzerlasten enthält, vorhanden ist.
5.2.2 Die Zulassung von privilegierten Containern minimieren (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAME:.metadata.name,POD_NAMESPACE:.metadata.namespace --no-headers | while read -r pod_name pod_namespace
do
# Retrieve container(s) for each Pod.
kubectl get pod "${pod_name}" --namespace "${pod_namespace}" -o json | jq -c '.spec.containers[]' | while read -r container
do
# Retrieve container's name.
container_name=$(echo ${container} | jq -r '.name')
# Retrieve container's .securityContext.privileged value.
container_privileged=$(echo ${container} | jq -r '.securityContext.privileged' | sed -e 's/null/notset/g')
if [ "${container_privileged}" = "false" ] || [ "${container_privileged}" = "notset" ] ; then
echo "***pod_name: ${pod_name} container_name: ${container_name} pod_namespace: ${pod_namespace} is_container_privileged: ${container_privileged} is_compliant: true"
else
echo "***pod_name: ${pod_name} container_name: ${container_name} pod_namespace: ${pod_namespace} is_container_privileged: ${container_privileged} is_compliant: false"
fi
done
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true'
Zurückgegebener Wert:
***pod_name: coredns-645bdb8675-sm78l container_name: coredns pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: helm-install-traefik-4qhld container_name: helm pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: helm-install-traefik-crd-dqkpt container_name: helm pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: local-path-provisioner-ffbcc4db4-pzhw4 container_name: local-path-provisioner pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: metrics-server-8677f8544d-kg66f container_name: metrics-server pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 container_name: lb-tcp-80 pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 container_name: lb-tcp-443 pod_namespace: kube-system is_container_privileged: notset is_compliant: true
***pod_name: traefik-5b6d9f7f5c-rs5sw container_name: traefik pod_namespace: kube-system is_container_privileged: notset is_compliant: trueBehebung:
Fügen Sie in jedem Namespace, der Benutzerlasten enthält, Richtlinien hinzu, um die Zulassung von privilegierten Containern einzuschränken.
Audit: Das Audit listet alle Container der Pods auf, um deren .securityContext.privileged-Wert abzurufen.
Bedingung: is_compliant ist falsch, wenn der .securityContext.privileged des Containers auf true gesetzt ist.
Standard: Standardmäßig gibt es keine Einschränkungen bei der Erstellung von privilegierten Containern.
5.2.3 Die Zulassung von Containern, die den Host-Prozess-ID-Namespace teilen möchten, minimieren (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAME:.metadata.name,POD_NAMESPACE:.metadata.namespace --no-headers | while read -r pod_name pod_namespace
do
# Retrieve spec.hostPID for each pod.
pod_hostpid=$(kubectl get pod "${pod_name}" --namespace "${pod_namespace}" -o jsonpath='{.spec.hostPID}' 2>/dev/null)
if [ -z "${pod_hostpid}" ]; then
pod_hostpid="false"
echo "***pod_name: ${pod_name} pod_namespace: ${pod_namespace} is_pod_hostpid: ${pod_hostpid} is_compliant: true"
else
echo "***pod_name: ${pod_name} pod_namespace: ${pod_namespace} is_pod_hostpid: ${pod_hostpid} is_compliant: false"
fi
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true'
Rückgabewert:
***pod_name: coredns-645bdb8675-sm78l pod_namespace: kube-system is_pod_hostpid: false is_compliant: true
***pod_name: helm-install-traefik-4qhld pod_namespace: kube-system is_pod_hostpid: false is_compliant: true
***pod_name: helm-install-traefik-crd-dqkpt pod_namespace: kube-system is_pod_hostpid: false is_compliant: true
***pod_name: local-path-provisioner-ffbcc4db4-pzhw4 pod_namespace: kube-system is_pod_hostpid: false is_compliant: true
***pod_name: metrics-server-8677f8544d-kg66f pod_namespace: kube-system is_pod_hostpid: false is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 pod_namespace: kube-system is_pod_hostpid: false is_compliant: true
***pod_name: traefik-5b6d9f7f5c-rs5sw pod_namespace: kube-system is_pod_hostpid: false is_compliant: trueBehebung:
Fügen Sie in jedem Namespace, der Benutzerlasten enthält, Richtlinien hinzu, um die Zulassung von hostPID Containern einzuschränken.
Audit: Das Audit ruft die spec.hostPID jedes Pods ab.
Bedingung: is_compliant ist falsch, wenn die spec.hostPID des Pods auf true gesetzt ist.
Standard: Standardmäßig gibt es keine Einschränkungen bei der Erstellung von hostPID-Containern.
5.2.4 Minimieren Sie die Zulassung von Containern, die den IPC-Namespace des Hosts teilen möchten (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAME:.metadata.name,POD_NAMESPACE:.metadata.namespace --no-headers | while read -r pod_name pod_namespace
do
# Retrieve spec.hostIPC for each pod.
pod_hostipc=$(kubectl get pod "${pod_name}" --namespace "${pod_namespace}" -o jsonpath='{.spec.hostIPC}' 2>/dev/null)
if [ -z "${pod_hostipc}" ]; then
pod_hostipc="false"
echo "***pod_name: ${pod_name} pod_namespace: ${pod_namespace} is_pod_hostipc: ${pod_hostipc} is_compliant: true"
else
echo "***pod_name: ${pod_name} pod_namespace: ${pod_namespace} is_pod_hostipc: ${pod_hostipc} is_compliant: false"
fi
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true'
Rückgabewert:
***pod_name: coredns-645bdb8675-sm78l pod_namespace: kube-system is_pod_hostipc: false is_compliant: true
***pod_name: helm-install-traefik-4qhld pod_namespace: kube-system is_pod_hostipc: false is_compliant: true
***pod_name: helm-install-traefik-crd-dqkpt pod_namespace: kube-system is_pod_hostipc: false is_compliant: true
***pod_name: local-path-provisioner-ffbcc4db4-pzhw4 pod_namespace: kube-system is_pod_hostipc: false is_compliant: true
***pod_name: metrics-server-8677f8544d-kg66f pod_namespace: kube-system is_pod_hostipc: false is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 pod_namespace: kube-system is_pod_hostipc: false is_compliant: true
***pod_name: traefik-5b6d9f7f5c-rs5sw pod_namespace: kube-system is_pod_hostipc: false is_compliant: trueBehebung:
Richtlinien zu jedem Namespace im Cluster hinzufügen, der Benutzerlasten hat, um die Zulassung von hostIPC Containern einzuschränken.
Audit: Das Audit ruft die spec.IPC jedes Pods ab.
Bedingung: is_compliant ist falsch, wenn die spec.hostIPC des Pods auf true gesetzt ist.
Standard: Standardmäßig gibt es keine Einschränkungen für die Erstellung von hostIPC-Containern.
5.2.5 Minimieren Sie die Zulassung von Containern, die den Netzwerk-Namespace des Hosts teilen möchten (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAME:.metadata.name,POD_NAMESPACE:.metadata.namespace --no-headers | while read -r pod_name pod_namespace
do
# Retrieve spec.hostNetwork for each pod.
pod_hostnetwork=$(kubectl get pod "${pod_name}" --namespace "${pod_namespace}" -o jsonpath='{.spec.hostNetwork}' 2>/dev/null)
if [ -z "${pod_hostnetwork}" ]; then
pod_hostnetwork="false"
echo "***pod_name: ${pod_name} pod_namespace: ${pod_namespace} is_pod_hostnetwork: ${pod_hostnetwork} is_compliant: true"
else
echo "***pod_name: ${pod_name} pod_namespace: ${pod_namespace} is_pod_hostnetwork: ${pod_hostnetwork} is_compliant: false"
fi
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true'
Rückgabewert:
***pod_name: coredns-645bdb8675-sm78l pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: true
***pod_name: helm-install-traefik-4qhld pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: true
***pod_name: helm-install-traefik-crd-dqkpt pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: true
***pod_name: local-path-provisioner-ffbcc4db4-pzhw4 pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: true
***pod_name: metrics-server-8677f8544d-kg66f pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: true
***pod_name: traefik-5b6d9f7f5c-rs5sw pod_namespace: kube-system is_pod_hostnetwork: false is_compliant: trueBehebung:
Fügen Sie in jedem Namespace, der Benutzerlasten enthält, Richtlinien hinzu, um die Zulassung von hostNetwork Containern einzuschränken.
Audit: Das Audit ruft die spec.hostNetwork jedes Pods ab.
Bedingung: is_compliant ist falsch, wenn die spec.hostNetwork des Pods auf true gesetzt ist.
Standard: Standardmäßig gibt es keine Einschränkungen für die Erstellung von hostNetwork-Containern.
5.2.6 Minimieren Sie die Zulassung von Containern mit allowPrivilegeEscalation (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAME:.metadata.name,POD_NAMESPACE:.metadata.namespace --no-headers | while read -r pod_name pod_namespace
do
# Retrieve container(s) for each Pod.
kubectl get pod "${pod_name}" --namespace "${pod_namespace}" -o json | jq -c '.spec.containers[]' | while read -r container
do
# Retrieve container's name
container_name=$(echo ${container} | jq -r '.name')
# Retrieve container's .securityContext.allowPrivilegeEscalation
container_allowprivesc=$(echo ${container} | jq -r '.securityContext.allowPrivilegeEscalation' | sed -e 's/null/notset/g')
if [ "${container_allowprivesc}" = "false" ] || [ "${container_allowprivesc}" = "notset" ]; then
echo "***pod_name: ${pod_name} container_name: ${container_name} pod_namespace: ${pod_namespace} is_container_allowprivesc: ${container_allowprivesc} is_compliant: true"
else
echo "***pod_name: ${pod_name} container_name: ${container_name} pod_namespace: ${pod_namespace} is_container_allowprivesc: ${container_allowprivesc} is_compliant: false"
fi
done
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'true'
Rückgabewert:
***pod_name: coredns-645bdb8675-sm78l container_name: coredns pod_namespace: kube-system is_container_allowprivesc: false is_compliant: true
***pod_name: helm-install-traefik-4qhld container_name: helm pod_namespace: kube-system is_container_allowprivesc: false is_compliant: true
***pod_name: helm-install-traefik-crd-dqkpt container_name: helm pod_namespace: kube-system is_container_allowprivesc: false is_compliant: true
***pod_name: local-path-provisioner-ffbcc4db4-pzhw4 container_name: local-path-provisioner pod_namespace: kube-system is_container_allowprivesc: notset is_compliant: true
***pod_name: metrics-server-8677f8544d-kg66f container_name: metrics-server pod_namespace: kube-system is_container_allowprivesc: false is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 container_name: lb-tcp-80 pod_namespace: kube-system is_container_allowprivesc: notset is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 container_name: lb-tcp-443 pod_namespace: kube-system is_container_allowprivesc: notset is_compliant: true
***pod_name: traefik-5b6d9f7f5c-rs5sw container_name: traefik pod_namespace: kube-system is_container_allowprivesc: false is_compliant: trueBehebung:
Fügen Sie Richtlinien zu jedem Namespace im Cluster hinzu, der Benutzerlasten hat, um die Zulassung von Containern mit .securityContext.allowPrivilegeEscalation auf true zu beschränken.
Audit: Das Audit ruft die Container jedes Pods .securityContext.allowPrivilegeEscalation ab.
Bedingung: is_compliant ist falsch, wenn .securityContext.allowPrivilegeEscalation des Containers auf true gesetzt ist.
Standardwert: Wenn nicht gesetzt, ist eine Privilegieneskalation erlaubt (Standard auf wahr). Wenn jedoch PSP/PSA mit einem restricted Profil verwendet wird, ist die Privilegieneskalation ausdrücklich nicht erlaubt, es sei denn, es ist anders konfiguriert.
5.2.7 Minimieren Sie die Zulassung von Root-Containern (Manuell)
Ergebnis: WARN
Behebung:
Erstellen Sie eine Richtlinie für jeden Namespace im Cluster und stellen Sie sicher, dass entweder MustRunAsNonRoot oder MustRunAs mit dem Bereich der UIDs, der 0 nicht einschließt, gesetzt ist.
5.2.8 Minimieren Sie die Zulassung von Containern mit der NET_RAW-Fähigkeit (Manuell)
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 zu beschränken.
5.2.9 Minimieren Sie die Zulassung von Containern mit hinzugefügten Fähigkeiten (Manuell)
Ergebnis: PASS
Revision:
kubectl get pods --all-namespaces -o custom-columns=POD_NAME:.metadata.name,POD_NAMESPACE:.metadata.namespace --no-headers | while read -r pod_name pod_namespace
do
# Retrieve container(s) for each Pod.
kubectl get pod "${pod_name}" --namespace "${pod_namespace}" -o json | jq -c '.spec.containers[]' | while read -r container
do
# Retrieve container's name
container_name=$(echo ${container} | jq -r '.name')
# Retrieve container's added capabilities
container_caps_add=$(echo ${container} | jq -r '.securityContext.capabilities.add' | sed -e 's/null/notset/g')
# Set is_compliant to true by default.
is_compliant=true
is_whitelist=false
caps_list=""
# Check if pod is in whitelist
if echo "${pod_name}" | grep -q -E "^(coredns|svclb-traefik)"; then
is_whitelist=true
is_compliant=true
elif [ "${container_caps_add}" != "notset" ]; then
# Loop through all caps and append caps_list, then set is_compliant to false.
for cap in $(echo "${container_caps_add}" | jq -r '.[]'); do
caps_list="${caps_list}${cap},"
is_compliant=false
done
# Remove trailing comma for the last list member.
caps_list=${caps_list%,}
fi
# Remove newlines from final output.
continaer_caps_add=$(echo "${container_caps_add}" | tr -d '\n')
if [ "${is_whitelist}" = true ]; then
printf "***pod_name: %-30s container_name: %-30s pod_namespace: %-20s is_whitelist: %-5s is_compliant: true\n" "${pod_name}" "${container_name}" "${pod_namespace}" "${is_whitelist}"
elif [ "${is_compliant}" = true ]; then
printf "***pod_name: %-30s container_name: %-30s pod_namespace: %-20s container_caps_add: %-15s is_compliant: true\n" "${pod_name}" "${container_name}" "${pod_namespace}" "${container_caps_add}"
else
printf "***pod_name: %-30s container_name: %-30s pod_namespace: %-20s container_caps_add: %-15s is_compliant: false\n" "${pod_name}" "${container_name}" "${pod_namespace}" "${caps_list}"
fi
done
doneErwartetes Ergebnis: 'is_compliant' ist gleich 'wahr'
Rückgabewert:
***pod_name: coredns-645bdb8675-sm78l container_name: coredns pod_namespace: kube-system is_whitelist: true is_compliant: true
***pod_name: helm-install-traefik-4qhld container_name: helm pod_namespace: kube-system container_caps_add: notset is_compliant: true
***pod_name: helm-install-traefik-crd-dqkpt container_name: helm pod_namespace: kube-system container_caps_add: notset is_compliant: true
***pod_name: local-path-provisioner-ffbcc4db4-pzhw4 container_name: local-path-provisioner pod_namespace: kube-system container_caps_add: notset is_compliant: true
***pod_name: metrics-server-8677f8544d-kg66f container_name: metrics-server pod_namespace: kube-system container_caps_add: notset is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 container_name: lb-tcp-80 pod_namespace: kube-system is_whitelist: true is_compliant: true
***pod_name: svclb-traefik-01b74a90-k47w2 container_name: lb-tcp-443 pod_namespace: kube-system is_whitelist: true is_compliant: true
***pod_name: traefik-5b6d9f7f5c-rs5sw container_name: traefik pod_namespace: kube-system container_caps_add: notset is_compliant: trueBehebung:
Stellen Sie sicher, dass allowedCapabilities nicht in den Richtlinien für den Cluster vorhanden ist, es sei denn, es ist auf ein leeres Array gesetzt.
Audit: Das Audit ruft die hinzugefügten Fähigkeiten der Container jedes Pods ab.
Bedingung: is_compliant ist falsch, wenn für einen bestimmten Container hinzugefügte Fähigkeiten vorhanden sind.
Standardwert: Container werden mit einem standardmäßigen Satz von Fähigkeiten ausgeführt, die von der Container-Laufzeit zugewiesen werden.
K3s gibt Ausnahmen für die folgenden Pods, die für den regulären Betrieb erforderlich sind: - coredns, svclb-traefik
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 für den Betrieb keine Linux-Fähigkeiten benötigen, ziehen Sie in Erwägung, eine PSP hinzuzufügen, die die Zulassung von Containern verbietet, die nicht alle Fähigkeiten abgeben.
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, die .securityContext.windowsOptions.hostProcess auf true gesetzt sind, einzuschränken.
5.3 Netzwerk-Richtlinien und CNI
5.3.1 Stellen Sie sicher, dass die 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.4 Geheimnisverwaltung
5.6 Allgemeine Richtlinien
5.6.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.6.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.6.3 Wenden Sie SecurityContext auf Ihre Pods und Container an (Manuell)
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 Security Benchmark für Docker-Container wenden.