Certified Kubernetes Security Specialist (CKS): Zertifizierungsvorbereitung

• Tag 1: Domain 1 - Cluster Setup (15 %) und Domain 2 - Cluster Hardening (15 %)
• 1. Cluster Setup: sichere Cluster-Komponenten
  • CIS Kubernetes Benchmark mit kube-bench: Prüfung von kube-apiserver, etcd, kubelet, CoreDNS, scheduler, controller-manager.
  • TLS-Konfiguration für API-Server, kubelet und etcd; Zertifikats-Lifecycle und -Rotation.
  • Ingress-Sicherheit: TLS-Termination, sichere Annotations, Schutz vor häufigen Misconfigurations.
  • Knoten-Metadaten und Cloud-Provider-Endpunkte schützen (AWS IMDSv2, Azure IMDS, GCP Metadata).
  • Kubernetes Dashboard und GUI-Zugriff minimieren oder vermeiden.
  • Plattform-Binärdateien überprüfen (Hashes, Signaturen).
  • Network Policies mit Default-Deny als Cluster-Baseline.
  • Praxis-Übung:  kube-bench-Audit auf einem Beispiel-Cluster ausführen, drei kritische  Findings beheben (TLS-Konfiguration, Audit-Logging, anonymous Auth  abschalten); Default-Deny Network Policy für ein Namespace umsetzen.

• 2. Cluster Hardening: API-Sicherheit und RBAC
  • Beschränkung des Zugriffs auf die Kubernetes-API: anonymous Auth abschalten, sichere Authentifizierungs-Methoden.
  • Role-Based Access Control (RBAC): Roles, ClusterRoles, RoleBindings, ClusterRoleBindings; Least-Privilege-Patterns.
  • Service Accounts: automatische Token-Mountings deaktivieren, sichere Token-Verwendung mit Audience-bound Tokens.
  • Kubernetes regelmässig aktualisieren: kubeadm-Upgrade-Strategie, Node-Drain, Skip-Versionen, Sicherheits-Releases.
  • etcd-Verschlüsselung at Rest: EncryptionConfiguration, KMS-Provider, Key Rotation.
  • Praxis-Übung:  RBAC für ein Multi-Team-Cluster entwerfen mit zwei Service Accounts,  Least-Privilege-Policy; etcd-Verschlüsselung at Rest aktivieren und mit  verschlüsseltem Beispiel-Secret verifizieren.

• Tag 2: Domain 3 - System Hardening (10 %) und Domain 4 - Minimize Microservice Vulnerabilities (20 %)
• 3. System Hardening: Host-OS und Kernel
  • Host-OS-Angriffsfläche  reduzieren: minimale Distributionen (Bottlerocket, Talos, Flatcar),  unnötige Pakete entfernen, automatische Sicherheitsupdates.
  • IAM-Rollen für Cloud-Worker minimieren: Pod-bound Identities (IRSA, Workload Identity), Vermeidung von Node-IAM-Vererbung.
  • Externer Netzwerkzugriff minimieren: Security Groups, NACLs, Bastion-Konzepte für Cluster-Operations.
  • Kernel-Hardening-Tools: AppArmor und seccomp Profile für Pods, Beispiel-Profile (RuntimeDefault, Localhost), Profile-Distribution auf Nodes.
  • Linux-Capabilities: capabilities drop, fine-grained Privilege-Reduzierung in Containern.
  • Praxis-Übung:  Ein Pod-Manifest hardening: seccomp RuntimeDefault, AppArmor-Profil,  Capabilities-Drop auf "all" mit gezieltem Hinzufügen, runAsNonRoot,  readOnlyRootFilesystem.

• 4. Minimize Microservice Vulnerabilities: PSA, OPA, Kyverno und Sandboxing
  • Pod Security Admission (PSA) und Pod Security Standards (Privileged, Baseline, Restricted): Namespace-Labeling, Enforce/Audit/Warn-Modi.
  • Migration von Pod Security Policies (PSP, in K8s 1.25 entfernt) zu PSA und Policy-Engines.
  • Open Policy Agent (OPA) Gatekeeper und Kyverno als Policy-Engines: Constraint Templates, Policies, ValidatingAdmissionPolicy.
  • Security Contexts auf Pod- und Container-Ebene: SecurityContext-Felder, fsGroup, supplementalGroups.
  • Kubernetes  Secrets: Encryption at Rest, externe Secret Stores (External Secrets  Operator, Vault, AWS Secrets Manager), Vermeidung von Secrets in  Environment Variables.
  • Container-Sandboxing für mandantenfähige Umgebungen: gvisor und kata-Container als RuntimeClasses.
  • mTLS für Pod-zu-Pod-Verschlüsselung: Service Mesh (Istio, Linkerd, Cilium Service Mesh).
  • Praxis-Übung:  Namespace mit PSA "restricted" labeln und drei Pods migrieren, die  ursprünglich nicht-konform waren; Kyverno-Policy schreiben, die  Image-Pull aus nicht erlaubten Registries verbietet; gvisor-RuntimeClass für ein sensitive Workload aktivieren.

• Tag 3: Domain 5 - Supply Chain Security (20 %) und Domain 6 - Monitoring, Logging, Runtime Security (20 %)
• 5. Supply Chain Security: minimale Images, Signierung und Scanning
  • Minimal-Image-Strategien: Distroless, Alpine, Scratch; Multi-Stage-Builds für minimale Final-Images.
  • Image-Whitelisting: Admission Controllers für erlaubte Registries, ImagePolicyWebhook, Kyverno verifyImages.
  • Image-Signierung mit Cosign und Sigstore: Keyless Signing, Verifikation in Admission, Rekor Transparency Log.
  • Statische Analyse von Manifesten und Dockerfiles: Kubesec für YAML-Manifeste, KubeLinter für Best-Practice-Checks, hadolint für Dockerfiles.
  • Image Vulnerability Scanning mit Trivy: CVE-Datenbank, SBOM, Severity-Filtering, Integration in CI/CD.
  • Software Bill of Materials (SBOM) und SLSA-Levels: Begriffsklärung und praktische Bedeutung.
  • Praxis-Übung:  Dockerfile auf Distroless-Basis refaktorieren mit hadolint-Lint; Image  mit Cosign signieren und in Kyverno-Policy nur signierte Images  zulassen; Trivy-Scan eines bekannten Images mit CVE-Findings auswerten.

• 6. Monitoring, Logging und Runtime Security: Falco, Audit Logs und Forensik
  • Verhaltensanalyse von Systemaufrufen mit Falco: Default-Rules, Custom-Rules, Falcosidekick, Output-Channels.
  • Threat  Detection in Echtzeit: typische Angriffsmuster (Shell in Container,  Privilege Escalation, sensitive File Reads, Cryptomining).
  • Kubernetes  Audit Logs: Audit Policy konfigurieren (Metadata, Request,  RequestResponse, None), Backend-Konfiguration, Forwarding an SIEM.
  • Container-Runtime-Forensik mit crictl: Pods inspizieren, Logs ausserhalb der API auslesen, Investigation auf kompromittierten Nodes.
  • Container-Unveränderlichkeit: readOnlyRootFilesystem, Tmpfs für Schreibvorgänge, Image-Pull-Policies.
  • Incident-Response-Workflow: Pod isolieren mit Network Policy, Cordon/Drain für Node-Quarantäne, Forensik-Daten sichern.
  • Praxis-Übung:  Falco mit Custom-Rule für sensitive File Access (z. B. /etc/shadow im  Container) konfigurieren und Alert verifizieren; Audit Policy für  sensitive Namespace mit Logging-Level Metadata einrichten und Logs  auswerten; einen kompromittierten Pod mit Network Policy isolieren und  mit crictl forensisch untersuchen.

• Tag 4: Vertiefung, Prüfungsstrategie und Probeklausur
• 7. Vertiefung kritischer Themen und Tool-Vergleiche
  • Tool-Vergleich Policy-Engines: OPA Gatekeeper vs. Kyverno vs. ValidatingAdmissionPolicy - wann welche Variante.
  • Tool-Vergleich Image-Sicherheit: Trivy vs. Grype vs. Clair vs. Snyk - Funktionsumfang und Examen-Relevanz.
  • Tool-Vergleich Runtime: Falco vs. Tetragon (Cilium) vs. Tracee - wann welcher Stack.
  • Häufige  Stolperfallen im CKS-Examen: PSA-Label-Syntax,  Network-Policy-DNS-Egress, Falco-Rule-Reload, Audit-Policy-Pfad,  Cosign-Verifikation in Kyverno.
  • Praxis-Übung: Speed-Drill mit zwanzig häufig verwechselten Begriffspaaren in Karteikarten-Manier.

• 8. Prüfungsstrategie und Praxis-Workshop
• Prüfungsstrategie (45 Min):
  • CKS-Examen-Format:  2 Stunden, 15-20 performance-based Tasks, Pass-Score 67 %, K8s v1.34,  ausschliesslich Englisch, PSI-Bridge-Browser-Umgebung mit mehreren  Cluster-Kontexten.
  • Erlaubte  Dokumentation: kubernetes.io, falco.org, trivy.dev, sigstore.dev,  kyverno.io, gatekeeper.gatekeeper.sh, aquasec/trivy GitHub - kein  Wechsel zu anderen Domains.
  • Drei-Pass-Strategie:  Quick Wins zuerst, komplexe Tasks danach, Validierung am Ende; nie  Tasks unbeantwortet lassen wegen partieller Punktevergabe.
  • Anti-Patterns:  Ctrl+W im PSI-Browser (schliesst Tab), Reboot der Base-Node, fehlende  Validierung von Network Policies mit DNS-Egress, fehlendes  kubectl-Alias-Setup zu Beginn.
  • Zeitmanagement: 7-8 Minuten pro Task im Schnitt, kubectl-Alias und Auto-Completion sofort nach Start einrichten.

• Praxis-Workshop (180 Min):
  • Phase 1 - Hands-on-Sprint (60 Min):  Drei reale Aufgaben (Network Policy mit Default Deny und gezielten  Allows, Cosign-Image-Verifikation in Kyverno, Falco-Custom-Rule mit  Verifikation) mit gegenseitigem Code-Review.
  • Phase 2 - Probeklausur unter Prüfungsbedingungen (90 Min):  12 performance-based Tasks über alle sechs Domänen in offizieller  Gewichtung, 90 Minuten als verkürzte Trainingseinheit, ohne Hilfsmittel  ausser erlaubter Dokumentation.
  • Phase 3 - Auswertung und Peer-Review (30 Min):  Score pro Domäne, Schwächenanalyse, Lernplan. Peer-Review der  schwierigsten Tasks: PSA-Migration vs. PSP, Cosign-Verifikation,  Falco-Rule-Format, Audit-Policy-Pfad, etcd-Encryption-Verifikation.

LernzieleJede teilnehmende Person verlässt das Seminar mit einem strukturierten Verständnis der sechs CKS-Prüfungsdomänen in offizieller Gewichtung (Cluster Setup 15 %, Cluster Hardening 15 %, System Hardening 10 %, Microservice Vulnerabilities 20 %, Supply Chain Security 20 %, Monitoring/Logging/Runtime Security 20 %), der Beherrschung der Pflicht-Tools des aktuellen Curriculums (Pod Security Admission, Falco, Trivy, Cosign/Sigstore, OPA Gatekeeper und Kyverno, AppArmor und seccomp, Kubesec und KubeLinter, crictl, kube-bench), der Routine in Cluster-Hardening (CIS Benchmark, RBAC mit Least Privilege, etcd-Verschlüsselung at Rest, Audit Policy), dem Werkzeug für Lieferkettensicherheit (minimale Images, Signierung, statische Manifest-Analyse, Vulnerability Scanning, Admission-basierte Image-Verifikation), der Praxis in Runtime-Threat-Detection (Falco-Custom-Rules, Audit-Logs, Container-Forensik mit crictl, Incident-Response-Patterns), einer absolvierten Probeklausur mit Domänen-Schwächenanalyse und einem persönlichen Lernplan - gut vorbereitet auf das CKS-Examen der CNCF.Zielgruppen

• Senior Kubernetes-Administratorinnen und -Administratoren mit CKA: Die ihre Plattform-Praxis um Sicherheits-Disziplin und Hardening-Verantwortung erweitern.
• DevSecOps- und Plattform-Engineers: Die Kubernetes-Cluster über Build, Deploy und Runtime hinweg absichern und Compliance-Anforderungen umsetzen.
• Security Engineers im Cloud-Native-Umfeld: Die Pod Security, Network Policies, Image-Signierung und Runtime-Threat-Detection produktiv einsetzen.
• Site Reliability Engineers mit Sicherheitsverantwortung: Die Audit-Logs, Incident Response und Lieferkettensicherheit für Kubernetes-Workloads operationalisieren.

Voraussetzungen: Bestandene Certified Kubernetes Administrator (CKA)-Prüfung als zwingende CNCF-Voraussetzung für die CKS-Prüfung.  Solide Routine in kubectl, YAML-Manifesten, Cluster-Architektur  (Control Plane, Nodes, kubeadm). Linux-CLI-Sicherheit,  Container-Grundlagen, Netzwerk- und TLS-Konzepte. Empfohlen: erste  Berührung mit Falco, Trivy oder OPA/Kyverno.Abgrenzung: Bereitet auf das CKS-Examen  der Cloud Native Computing Foundation vor (aktuelle Prüfungsversion auf Kubernetes v1.34/v1.35, Stand 2025/2026) - nicht auf CKA (Vorstufe und Pflichtvoraussetzung), nicht auf CKAD (Application Developer), nicht auf KCSA (Cloud Native Security Associate als entry-level Pendant), nicht auf vendor-spezifische Pendants wie Red Hat OpenShift Security oder AWS/Azure/GCP-Kubernetes-Security-Spezialisierungen. Hinweis: Die Prüfung ist nur in Englisch verfügbar.