CKS Zertifizierung 2026: Der haerteste Kubernetes-Test und wie Sie ihn bestehen

TL;DR

• Die CKS (Certified Kubernetes Security Specialist) ist die anspruchsvollste Kubernetes-Zertifizierung mit einer Bestehensquote von ca. 50%
• Voraussetzung: Eine gueltige CKA-Zertifizierung -- ohne CKA keine Zulassung
• Pruefungsdauer 2 Stunden, 67% zum Bestehen, rein praxisbasiert
• Kernthemen: Cluster Hardening, Supply Chain Security, Runtime Security (Falco), Netzwerk-Policies, Audit Logging
• Empfohlene Vorbereitung: 8-12 Wochen bei solider CKA-Basis und Security-Erfahrung

Warum die CKS so anspruchsvoll ist

Die CKS testet nicht nur Kubernetes-Wissen, sondern erwartet ein tiefes Verstaendnis von Linux-Security-Konzepten, Container-Sicherheit und Cloud-Native-Security-Tools. Waehrend die CKA prueft, ob Sie einen Cluster administrieren koennen, prueft die CKS, ob Sie einen Cluster absichern koennen.

Das bedeutet konkret: Sie muessen in der Pruefung mit Tools wie Falco, Trivy, AppArmor und Seccomp arbeiten, Audit Policies schreiben, RBAC korrekt einschraenken und Schwachstellen in laufenden Clustern finden und beheben.

Der Zertifizierungspfad

KCNA (optional) */} CKA (Pflicht) */} CKS
                */} CKAD (optional, parallel)

Die CKA muss zum Zeitpunkt der CKS-Pruefung gueltig sein. Planen Sie den Zeitraum entsprechend.

Falls Sie noch keine CKA haben, starten Sie mit unserem Kubernetes Zertifizierungs-Guide. Die CKAD koennen Sie parallel oder vorher ablegen -- Details im CKAD-Guide.

CKS Exam Domains (Curriculum 2026)

Die Domains 4, 5 und 6 machen zusammen 60% der Pruefung aus. Hier entscheidet sich, ob Sie bestehen.

Security-Konfigurationen, die Sie beherrschen muessen

Pod Security: Gehaerteter Pod

apiVersion: v1
kind: Pod
metadata:
  name: hardened-app
spec:
  automountServiceAccountToken: false
  securityContext:
    runAsNonRoot: true
    runAsUser: 10000
    runAsGroup: 10000
    fsGroup: 10000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: nginx:1.27
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop:
            - ALL
      resources:
        requests:
          cpu: 100m
          memory: 64Mi
        limits:
          cpu: 200m
          memory: 128Mi
      volumeMounts:
        - name: tmp
          mountPath: /tmp
        - name: cache
          mountPath: /var/cache/nginx
        - name: run
          mountPath: /var/run
  volumes:
    - name: tmp
      emptyDir: {}
    - name: cache
      emptyDir: {}
    - name: run
      emptyDir: {}

Wichtig: readOnlyRootFilesystem: true erfordert, dass Sie beschreibbare Verzeichnisse explizit als emptyDir-Volumes mounten.

RBAC: Least-Privilege Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "update", "patch"]
  - apiGroups: [""]
    resources: ["configmaps", "secrets"]
    verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-deployer-binding
  namespace: production
subjects:
  - kind: ServiceAccount
    name: deploy-sa
    namespace: production
roleRef:
  kind: Role
  name: app-deployer
  apiGroup: rbac.authorization.k8s.io

Pruefungstipp: Vermeiden Sie verbs: ["*"] oder resources: ["*"]. Jede ueberfluessige Berechtigung ist ein Punktabzug.

NetworkPolicy: Default Deny mit selektiver Freigabe

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Mehr zu NetworkPolicies in unserem Artikel zu Kubernetes Network Policies.

Audit Policy: API-Zugriffe protokollieren

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Secrets nur auf Metadata-Level loggen (keine Inhalte!)
  - level: Metadata
    resources:
      - group: ""
        resources: ["secrets"]
  # Alles in kube-system auf RequestResponse
  - level: RequestResponse
    namespaces: ["kube-system"]
  # Standardmaessig Request-Level
  - level: Request
    resources:
      - group: ""
        resources: ["pods", "services"]
      - group: "apps"
        resources: ["deployments"]

Vertiefung zum Thema: Kubernetes Audit Logging.

Security-Tools fuer die CKS-Pruefung

Trivy: Container-Image-Scanning

# Image auf Schwachstellen pruefen
trivy image nginx:1.27

# Nur kritische und hohe Schwachstellen anzeigen
trivy image --severity CRITICAL,HIGH nginx:1.27

# Ergebnis als JSON fuer CI/CD-Pipeline
trivy image --format json --output result.json nginx:1.27

In der Pruefung werden Sie aufgefordert, verwundbare Images zu identifizieren und durch sichere Versionen zu ersetzen.

Falco: Runtime-Security-Monitoring

# Beispiel Falco-Regel: Shell in Container erkennen
- rule: Terminal shell in container
  desc: Erkennt, wenn eine Shell in einem Container geoeffnet wird
  condition: >
    spawned_process and
    container and
    proc.name in (bash, sh, zsh) and
    not container.image.repository in (allowed_shell_images)
  output: >
    Shell in Container gestartet
    (user=%user.name container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [container, shell, mitre_execution]

# Falco-Events live beobachten
kubectl logs -f -l app.kubernetes.io/name=falco -n falco

# Falco mit Helm installieren
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco -n falco --create-namespace

AppArmor und Seccomp

# Pod mit AppArmor-Profil
apiVersion: v1
kind: Pod
metadata:
  name: apparmor-pod
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/restricted-profile
spec:
  containers:
    - name: app
      image: nginx:1.27
---
# Pod mit Seccomp-Profil
apiVersion: v1
kind: Pod
metadata:
  name: seccomp-pod
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/restricted.json
  containers:
    - name: app
      image: nginx:1.27

10-Wochen-Lernplan

Wochen 1-2: CKA-Wissen auffrischen

• RBAC, ServiceAccounts, Admission Controllers wiederholen
• Kubernetes-API-Server-Flags verstehen
• etcd-Backup und -Verschluesselung
• Alle kubectl auth can-i-Varianten beherrschen

Wochen 3-4: Cluster und System Hardening

• CIS Kubernetes Benchmark durcharbeiten (kube-bench)
• API-Server absichern: Anonymous Auth, NodeRestriction
• Kubelet-Security-Konfiguration
• AppArmor- und Seccomp-Profile schreiben und anwenden

Wochen 5-6: Supply Chain und Image Security

• Trivy fuer Image-Scanning einsetzen
• Private Registries absichern, Image-Allowlisting
• ImagePolicyWebhook konfigurieren
• SBOM-Grundlagen und Cosign fuer Image-Signierung

Wochen 7-8: Runtime Security und Monitoring

• Falco installieren, Regeln schreiben und testen
• Audit Policies konfigurieren und Events auswerten
• Immutable Containers und readOnlyRootFilesystem
• Verdaechtige Prozesse in laufenden Containern erkennen

Wochen 9-10: Pruefungssimulation

• killer.sh-Simulator (im Pruefungspreis enthalten) durcharbeiten
• Zeitmanagement: max. 7 Minuten pro Aufgabe
• Schwaechen gezielt wiederholen
• Zweiten killer.sh-Versuch fuer den Feinschliff nutzen

Kosten und Pruefungsdetails

Haeufige Fehler und wie Sie sie vermeiden

1. Zu wenig Linux-Security-Wissen. Die CKS setzt voraus, dass Sie AppArmor, Seccomp und grundlegende Linux-Sicherheitskonzepte verstehen. Reine Kubernetes-Kenntnisse reichen nicht.

2. RBAC-Regeln zu breit. In der Pruefung wird explizit nach Least-Privilege-Konfigurationen gefragt. Testen Sie mit kubectl auth can-i.

3. Falco nur installiert, aber nie benutzt. Sie muessen Falco-Regeln lesen, verstehen und anpassen koennen. Nur helm install reicht nicht.

4. Zeitmanagement unterschaetzt. Die CKS ist zeitlich extrem knapp. Uebersprungen und spaeter zurueckkommen ist besser als 15 Minuten an einer Aufgabe haengen.

5. Audit Policies nicht geuebt. Die verschiedenen Audit-Level (None, Metadata, Request, RequestResponse) muessen sitzen.

Karrierewirkung

Die CKS ist ein starkes Differenzierungsmerkmal, weil sie selten ist. Waehrend die CKA mittlerweile verbreitet ist, haben deutlich weniger Engineers die CKS. Das macht sie besonders wertvoll fuer:

• Security-fokussierte Rollen: DevSecOps Engineer, Cloud Security Architect
• Consulting: Kunden vertrauen zertifizierten Security-Spezialisten
• Regulated Industries: Finanzsektor, Healthcare, oeffentliche Verwaltung -- ueberall dort, wo Kubernetes-Security auditiert wird

Gehaltstechnisch koennen Sie mit CKA + CKS im deutschen Markt mit 15-30% mehr rechnen als ohne Zertifizierungen, je nach Erfahrung und Branche.

Weitere Infos zu Kubernetes-Security-Themen:

• Kubernetes Security Hardening
• Kubernetes Security Scanning
• Kubernetes RBAC im Enterprise

Fazit

Die CKS ist kein Zertifikat, das man nebenbei mitnimmt. Sie erfordert fundiertes Security-Wissen, praktische Erfahrung mit Security-Tools und schnelles Arbeiten unter Zeitdruck. Wer sie besteht, hat bewiesen, dass er Kubernetes-Cluster nicht nur betreiben, sondern auch absichern kann -- und das ist auf dem aktuellen Markt sehr gefragt.

Sie moechten Ihre Kubernetes-Umgebung professionell absichern oder Ihr Team auf die CKS vorbereiten? Informieren Sie sich ueber unsere Security-Audits und Consulting-Angebote.