Die Prüfung zum Certified Kubernetes Security Specialist (CKS) ist eine herstellerunabhängige, praxisorientierte Bewertung von Sicherheitsaufgaben in Kubernetes, die über die Befehlszeile an Kubernetes-Clustern durchgeführt werden. Derzeit wird Kubernetes v1.35 verwendet; da die Linux Foundation die Umgebung jedoch an aktuelle Kubernetes-Minor-Releases anpasst, sollten Sie die aktuelle Version und den Lehrplan überprüfen, bevor Sie sich auf bestimmte Befehle, Funktionen oder die Gewichtung der Themenbereiche verlassen. Die sechs Themenbereiche sind: Cluster-Einrichtung (15 %), Cluster-Härtung (15 %), Systemhärtung (10 %), Minimierung von Microservice-Schwachstellen (20 %), Sicherheit der Lieferkette (Supply Chain Security, 20 %) sowie Monitoring, Logging und Laufzeitsicherheit (20 %). Die Prüfung ist praxisorientiert und wird online beaufsichtigt: Sie lösen innerhalb von zwei Stunden mehrere Aufgaben über die Befehlszeile; Voraussetzung ist das vorherige Bestehen der Prüfung zum Certified Kubernetes Administrator (CKA).
Als Nächstes betrachten wir den Ablauf der Aufgaben und die aktuelle Verteilung der Themenbereiche.
Eine CKS-Aufgabe gilt als abgeschlossen, wenn der geforderte Sicherheitszustand hergestellt ist und Belege dafür vorliegen, dass der entsprechende Kubernetes-Mechanismus diesen Zustand durchsetzt. Das Auswendiglernen eines Befehls ermöglicht zwar das schnelle Erstellen eines Objekts, belegt jedoch nicht, dass eine Workload von einer Richtlinie erfasst wird, eine Identität nur über die beabsichtigten API-Berechtigungen verfügt oder eine Erkennungsregel das erwartete Laufzeitverhalten überwacht. Prüfen Sie die Anforderungen hinsichtlich Zielressource, Sicherheitsgrenze und erforderlichem Verifizierungsnachweis, bevor Sie Konfigurationsänderungen vornehmen.
Erstellen Sie unter Zeitdruck kleine, überprüfbare Artefakte. Dazu gehören üblicherweise ein Manifest, das den Soll-Zustand definiert, ein gezielter Befehl zur Anwendung oder Überprüfung dieses Zustands sowie eine Ausgabe, die das Objekt oder Verhalten nach der Änderung darstellt. Ein Manifest belegt die an die Kubernetes-API übermittelte Konfiguration. Die Ausgabe eines Befehls weist lediglich den aktuellen Zustand der Ressource oder die Antwort zum jeweiligen Zeitpunkt im gewählten Cluster und Namespace nach. Keines der beiden Elemente für sich allein belegt, dass sämtliche Pfade sicher sind.
Gehen Sie nach einem wiederholbaren Schema vor. Ermitteln Sie zunächst den aktiven Cluster-Kontext und den Ziel-Namespace. Untersuchen Sie anschließend die vorhandenen Objekte und Labels, die für die Auswahl von Richtlinien oder den Umfang von Berechtigungen maßgeblich sind. Führen Sie die minimale Änderung durch, die der jeweiligen Anforderung entspricht, und verifizieren Sie das Ergebnis anhand einer darauf abgestimmten Überprüfung. Bewahren Sie schließlich genügend Kontext, um fehlerhafte Änderungen rückgängig machen zu können – insbesondere bei Anpassungen der clusterweiten Konfiguration, von Node-Dateien oder API-Server-Einstellungen.
Operative Regel Bevorzugen Sie Nachweise, die sich auf die geforderte Sicherheitsgrenze beziehen, gegenüber vertrauten Befehlen, die nicht direkt damit zusammenhängende Ressourcen verändern.
Im Verlauf dieses Kurses sichern wir eine fiktive Workload aus dem Einzelhandelsbereich im Namespace shop ab. Ein Namespace ist ein Kubernetes-Geltungsbereich, der namensraumgebundene Ressourcen zusammenfasst und als Grenze für Berechtigungen sowie Richtlinien dienen kann. Die Workload verfügt über einen von außen erreichbaren Ingress-Pfad zu orders-api:1.0 auf Port 8080; diese Anwendung ruft payments-api:1.0 auf Port 8443 auf, und payments-api greift wiederum auf orders-db zu. In diesem Modell ist außer dem Ingress-Endpunkt keine weitere Workload von außerhalb des Clusters erreichbar.
Jede Anwendung nutzt einen eigenen ServiceAccount – eine Kubernetes-Identität, die ein Pod bei Aufrufen der Kubernetes-API verwenden kann. orders-api verwendet orders-sa, während payments-api payments-sa nutzt. Durch die Trennung dieser Identitäten können wir die Autorisierung nach dem Prinzip der geringsten Rechte (Least Privilege) unabhängig von Netzwerkerreichbarkeit, Image-Herkunft, Pod-Beschränkungen und Laufzeitsignalen überprüfen. Als wiederverwendbare Regel gilt: Identifizieren Sie den Workload-Pfad und die Identitätsgrenze, bevor Sie eine Sicherheitsmaßnahme auswählen.
Nun können wir die Workload-Grenze nachvollziehen, die von späteren Schutzmaßnahmen gewahrt werden muss.