Certified Kubernetes Security Specialist (CKS): Zertifizierungsvorbereitung

Seminarziel

Jede 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.

Inhalt

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.