CKS (Kubernetes Security Specialist): Voraussetzungen und ein 6-wöchiger Lernplan

CKS – Certified Kubernetes Security Specialist – ist meiner Meinung nach die schwierigste der drei professionellen Kubernetes-Prüfungen, enger als CKA und unter Zeitdruck gemeiner. Zwei Stunden, praxisorientiert, 445 $, inklusive kostenlosem Wiederholungsversuch. PSI Bridge, nur online, keine Testzentren. Die Bestehensquote liegt bei 67 %. CNCF veröffentlicht keine offiziellen Bestehensquoten, aber die von der Community ermittelte Quote für den ersten Versuch liegt bei etwa 40–50 %, niedriger als beim CKA, was meiner Erfahrung entspricht, wenn ich Kollegen dabei beobachte.

Was die meisten Leute übersehen: Man kann sich nicht einfach anmelden. CNCF verlangt bei der Anmeldung einen aktiven CKA in Ihrem Konto. Nicht "Sie haben den CKA irgendwann einmal gemacht." Sondern: Aktiv. Wenn Ihr CKA abgelaufen ist (was seit der Richtlinienänderung vom 1. April 2024 jetzt nach 2 statt 3 Jahren der Fall ist), müssen Sie ihn verlängern, bevor Sie sich für den CKS anmelden können. Dies ist eine strenge Anforderung, keine Empfehlung, und sie überrascht die Leute jedes Quartal.

Die wahren Voraussetzungen

Die offizielle: ein aktiver CKA. Das ist alles.

Die inoffiziellen:

• Vertrautheit mit kubectl, sodass Sie nicht über die Syntax nachdenken müssen. Wenn Sie immer noch nach "kubectl create deployment" googeln, sind Sie noch nicht bereit.
• Linux-Grundlagen — Sie werden sich per SSH auf Knoten verbinden, systemd-Journals lesen, kubelet-Flags bearbeiten und Fehler bei seccomp / AppArmor-Profilen debuggen. Wenn journalctl -u kubelet Ihnen unbekannt ist, beheben Sie das zuerst.
• vim-Kenntnisse. Keine Vim-Zauberei. Aber das Bearbeiten von YAML in vim innerhalb von 2 Stunden, ohne 30 Sekunden mit "Moment, wie speichere ich noch mal" zu verlieren, ist obligatorisch.
• Ein funktionierendes mentales Modell von NetworkPolicy. Dies ist der größte Stolperstein in der Prüfung. Mehr dazu weiter unten.
• Frühere Berührungspunkte mit Falco, Trivy, AppArmor, seccomp, mTLS über Service Mesh und Pod Security Standards. Sie müssen kein Experte in einem davon sein; Sie müssen sie erkennen können.

Wenn Ihnen mehr als zwei dieser Punkte fehlen, verbringen Sie einen weiteren Monat mit operationellen Übungen im CKA-Stil, bevor Sie sich an den CKS wagen. Der Versuch, Kubernetes-Operationen und -Sicherheit gleichzeitig unter Zeitdruck zu lernen, führt dazu, dass Sie den kostenlosen Wiederholungsversuch verschwenden.

Was tatsächlich getestet wird

Der CNCF-Lehrplan gliedert sich wie folgt (die Prozentsätze ändern sich mit jeder Lehrplanrevision; Stand: Anfang 2026):

• Cluster-Setup und -Härtung (~15%): CIS-Benchmarks, kube-bench, Einschränkung des externen Zugriffs, Deaktivierung anonymer Authentifizierung, kubelet-Härtungs-Flags.
• Systemhärtung (~15%): Kernel-Härtung (seccomp, AppArmor), Reduzierung der Angriffsfläche, IAM-Minimierung auf der Cloud-Seite.
• Minimierung von Microservice-Schwachstellen (~20%): Pod Security Standards (die PSPs in 1.25 ersetzten), ServiceAccount-Tokens, OPA / Gatekeeper oder Kyverno, mTLS.
• Supply-Chain-Sicherheit (~20%): Scannen von Images mit Trivy, Signieren mit cosign, Admission Controller, die unsignierte Images blockieren, SBOM-Grundlagen, Minimierung von Basis-Images.
• Monitoring, Logging, Laufzeitsicherheit (~20%): Falco-Regeln, Verhaltensanalysen, Unveränderlichkeit, Audit-Logging auf API-Server-Ebene.
• Netzwerkrichtlinien (~10%): Default-Deny, Namespace-Isolation, Egress-Regeln. Als kleiner Prozentsatz aufgeführt, aber in der Praxis berührt jede andere Kategorie auch NetworkPolicy.

Die Prüfung testet nicht, wie Falco intern funktioniert. Sie testet, ob Sie eine Falco-Regel schreiben können, die ausgelöst wird, wenn eine Shell in einem Container startet. Die Prüfung testet nicht die cosign-Kryptographie. Sie testet, ob Sie einen Admission Controller so konfigurieren können, dass er unsignierte Images ablehnt. Die Arbeit ist operativ, nicht akademisch.

Der 6-Wochen-Plan

Dies geht von etwa 10 Stunden pro Woche aus, mit einem bereits aktiven CKA in der Tasche. Passen Sie es an, wenn Sie mehr oder weniger Zeit haben.

Woche 1: NetworkPolicy bis zum Umfallen.

Richten Sie einen kind-Cluster lokal mit Calico oder Cilium ein (das Standard-kindnet erzwingt NetworkPolicy nicht, was viele Leute verwirrt). Schreiben Sie eine Default-Deny-Policy für einen Namespace. Schreiben Sie eine Allow-From-Namespace-Policy. Schreiben Sie eine Egress-Policy, die nur DNS erlaubt. Schreiben Sie eine, die Traffic von einem bestimmten Pod-Label über Namespaces hinweg erlaubt. Wiederholen Sie all dies aus dem Gedächtnis, bis Sie sie in vim schreiben können, ohne kubernetes.io zu konsultieren. NetworkPolicy-YAML ist der inhaltsreichste Bereich in der Prüfung und derjenige, bei dem die meisten Leute Fehler machen. Verbringen Sie hier mehr Zeit, als Sie für nötig halten.

Woche 2: Pod Security Standards, ServiceAccounts, RBAC-Verschärfung.

Wenden Sie Restricted-, Baseline- und Privileged-Profile auf Namespaces an. Konfigurieren Sie ServiceAccounts mit automountServiceAccountToken: false. Erstellen Sie RBAC, das dem Prinzip der geringsten Rechte für ein Deployment folgt, das ConfigMaps in seinem eigenen Namespace und nichts weiter lesen muss. Üben Sie die Diagnose von "dieser Pod kann X nicht tun wegen RBAC", bis der kubectl auth can-i-Flow automatisch abläuft.

Woche 3: Lieferkette — Trivy, cosign, Admission Control.

Scannen Sie ein Image mit Trivy und interpretieren Sie die CVE-Ausgabe. Signieren Sie ein Image mit cosign. Konfigurieren Sie einen ImagePolicyWebhook oder eine Kyverno-Policy, die Images ablehnt, die nicht mit Ihrem Schlüssel signiert sind. Richten Sie eine lokale OCI-Registry ein, wenn Sie umfassende Übungen wünschen. Die Prüfung wird Ihnen wahrscheinlich Trivy installiert zur Verfügung stellen; Sie sollten seine wichtigsten Flags auswendig kennen (--severity HIGH,CRITICAL, --ignore-unfixed).

Woche 4: Laufzeit — Falco, AppArmor, seccomp.

Installieren Sie Falco auf einem kind-Cluster. Lesen Sie die Standardregeln. Schreiben Sie eine benutzerdefinierte Regel. Wenden Sie ein AppArmor-Profil auf einen Pod an (die Prüfung gibt Ihnen typischerweise ein Profil, das bereits auf dem Knoten vorhanden ist, und bittet Sie, es über eine Annotation zu verbinden – was bedeutet, die Syntax container.apparmor.security.beta.kubernetes.io/<container>: localhost/<profile> zu kennen). Wenden Sie ein seccomp-Profil über securityContext.seccompProfile an. Beide haben eine annotationsbasierte Legacy-Syntax und eine feldbasierte aktuelle Syntax; die Prüfung testet tendenziell die aktuelle Syntax, aber Sie sollten beide erkennen.

Woche 5: Cluster- und Host-Härtung.

Führen Sie kube-bench aus, interpretieren Sie die Fehler, beheben Sie die einfachen (anonyme Authentifizierung, Audit-Logging, kubelet-Flags). Konfigurieren Sie die Audit-Richtlinie auf dem API-Server. Beschränken Sie den etcd-Zugriff. Deaktivieren Sie unnötige kubelet-Ports. Dies ist hauptsächlich Linux-Arbeit auf Knotenebene und der Bereich, in dem Ingenieure ohne starke Systemadministrator-Hintergründe langsamer werden.

Woche 6: Killer Shell, vollständige Simulationen und Ruhe.

Nutzen Sie in dieser Woche beide enthaltenen Killer Shell-Sitzungen. Sie sind absichtlich schwerer als die echte Prüfung; erwarten Sie, schlechter abzuschneiden, als Sie hoffen. Nutzen Sie die Lücken zum Lernen. Legen Sie die eigentliche Prüfung in den letzten 2–3 Tagen von Woche 6 ab, solange das Muskelgedächtnis frisch ist. Schieben Sie es nicht weiter auf – jede Woche, die Sie verzögern, verlieren Sie Reflexe.

Schlafen Sie in der Nacht davor. Machen Sie keine Lern-Nachtschicht. Ändern Sie Ihre kubectl-Aliase nicht am Tag der Prüfung.

Die häufigsten Stolpersteine

NetworkPolicy unter Zeitdruck. Schon erwähnt und es lohnt sich, es zweimal zu sagen. Die YAML-Struktur ist unerbittlich – falsche Einrückung legt die Policy stillschweigend lahm, und der Pod routet weiterhin. Üben Sie in vim, bis Sie eine Default-Deny + selektive Allow-Regel aus dem Muskelgedächtnis schreiben können.

Vergessen, dass NetworkPolicy ein CNI benötigt, das sie durchsetzt. kindnet tut es nicht. flannel (Standard in einigen Setups) tut es nicht. Calico, Cilium, Weave tun es. Stellen Sie sicher, dass Ihr Übungscluster ein durchsetzendes CNI verwendet, sonst lernen Sie die falschen Lektionen.

Verwechslung von PSP und Pod Security Standards. PSPs wurden in 1.25 entfernt (schon vor Jahren, aber altes Schulungsmaterial verweist immer noch darauf). Der aktuelle Mechanismus ist Pod Security Admission mit den Profilen restricted, baseline und privileged, die über Namespace-Labels angewendet werden. Studieren Sie keine PSPs.

etcd Encryption-at-rest-Konfiguration. Wird oft getestet. Insbesondere: Bearbeiten der EncryptionConfiguration, Neustarten des API-Servers mit dem richtigen Flag und Überprüfen mit etcdctl get, ob der Wert verschlüsselt ist. Üben Sie dies.

Die Browser-Tab-Falle. Sie dürfen kubernetes.io, falco.org, app-armor.net und einige andere verwenden. Sie können sich unter Zeitdruck nicht darauf verlassen, sie zu durchsuchen. Merken Sie sich die Struktur. Verwenden Sie den Tab, um bestimmte Snippets zu kopieren und einzufügen, nicht um Syntax zu lernen.

Sollten Sie ihn ablegen?

Legen Sie den CKS ab, wenn Ihre Aufgabe Plattform-Sicherheit, Security Engineering in einem Kubernetes-Umfeld oder Compliance-Arbeit in regulierten Branchen ist oder sein wird. Überspringen Sie ihn, wenn Sie ein Generalist im Plattform-Engineering sind – der CKA deckt ab, was die meisten Generalistenrollen benötigen, und der CKS ist überflüssig und läuft nach 2 Jahren ab.

Wenn Sie ihn anstreben, durchsuchen Sie die CKS-Fragensammlung auf CertLabPro oder starten Sie eine zeitgesteuerte Prüfung. Die konzeptionelle Abdeckung in Fragensammlungen ergänzt die operativen Übungen, die Sie auf echten Clustern durchführen müssen. Beides ist notwendig; keines allein ist ausreichend.