CKS Vorbereitung: Security-Tools die du beherrschen musst

TL;DR

Die CKS-Pruefung verlangt praktische Erfahrung mit mindestens 7 Security-Tools -- Trivy, Falco, AppArmor, Seccomp, kube-bench, OPA Gatekeeper und NetworkPolicies.
Jedes Tool muss in der Pruefung korrekt eingesetzt werden koennen -- Installation, Konfiguration und Fehlerbehebung.
Trivy fuer Image-Scanning und Falco fuer Runtime-Security machen zusammen ca. 40% der pruefungsrelevanten Aufgaben aus.
AppArmor und Seccomp sind Linux-Security-Mechanismen, die ihr am Host und im Pod konfigurieren muesst.
Dieser Guide liefert fuer jedes Tool die pruefungsrelevanten Befehle und Konfigurationen zum Nacharbeiten.

Warum Tool-Kenntnisse bei der CKS entscheiden

Die CKS (Certified Kubernetes Security Specialist) ist eine rein praxisbasierte Pruefung. Ihr arbeitet in einem Live-Cluster und muesst Security-Probleme finden und beheben. Theoretisches Wissen reicht nicht -- ihr muesst die Tools bedienen koennen.

In diesem Guide behandeln wir jedes pruefungsrelevante Tool mit den Befehlen und Konfigurationen, die ihr in der CKS benoetigt. Arbeitet jeden Abschnitt praktisch nach -- idealerweise in einem eigenen Testcluster.

Fuer den vollstaendigen Ueberblick ueber die CKS-Pruefung empfehlen wir unseren CKS Zertifizierungs-Guide.

1. Trivy: Container Image Scanning

Trivy ist das Standard-Tool fuer Image-Scanning in der CKS-Pruefung. Ihr muesst Images scannen und Schwachstellen nach Severity filtern koennen.

Installation

# Installation auf Debian/Ubuntu
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update && sudo apt-get install trivy

Pruefungsrelevante Befehle

# Vollstaendiger Image-Scan
trivy image nginx:1.27

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

# Scan mit Exit-Code (fuer CI/CD und Pruefungsaufgaben)
trivy image --exit-code 1 --severity CRITICAL nginx:1.27

# Bestimmte Schwachstellen-IDs ignorieren
trivy image --ignore-unfixed nginx:1.27

# Scan eines lokalen Images (nach docker build)
trivy image --input image.tar

# Filesystem-Scan (fuer Dockerfile-Analyse)
trivy fs --severity HIGH,CRITICAL /path/to/project

Typische CKS-Aufgabe

Die Aufgabe koennte lauten: "Scanne alle Images im Namespace production und identifiziere Container mit CRITICAL Schwachstellen."

# Alle Images im Namespace auflisten
kubectl get pods -n production -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | sort -u

# Jedes Image einzeln scannen
trivy image --severity CRITICAL your-registry/app:v1.2.3

2. Falco: Runtime Security Monitoring

Falco ist ein Runtime-Security-Tool, das verdaechtige Aktivitaeten in laufenden Containern erkennt. In der CKS muesst ihr Falco-Regeln lesen, verstehen und anpassen koennen.

Installation

# Installation via Helm
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set falcosidekick.enabled=true

# Alternativ: Installation via apt (fuer Single-Node)
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] https://download.falco.org/packages/deb stable main" | sudo tee /etc/apt/sources.list.d/falcosecurity.list
sudo apt-get update && sudo apt-get install falco

Falco-Regeln verstehen

Falco-Regeln bestehen aus drei Elementen: Macros, Lists und Rules.

# Beispiel: Custom Falco Rule
# Datei: /etc/falco/rules.d/custom-rules.yaml

- list: allowed_processes
  items: [nginx, node, python3]

- macro: container_started
  condition: evt.type=execve and container.id != host

- rule: Unauthorized Process in Container
  desc: Detect processes not in the allowed list running in containers
  condition: >
    container_started
    and not proc.name in (allowed_processes)
  output: >
    Unauthorized process started
    (user=%user.name command=%proc.cmdline container=%container.name
    image=%container.image.repository)
  priority: WARNING
  tags: [container, process]

Pruefungsrelevante Befehle

# Falco-Logs pruefen (systemd)
journalctl -u falco --no-pager | tail -50

# Falco-Logs pruefen (Kubernetes)
kubectl logs -n falco -l app.kubernetes.io/name=falco --tail=100

# Falco-Konfiguration pruefen
cat /etc/falco/falco.yaml

# Custom Rules laden (Neustart erforderlich)
sudo systemctl restart falco

# Falco im Vordergrund starten (Debugging)
sudo falco -r /etc/falco/rules.d/custom-rules.yaml

Typische CKS-Aufgabe

"Erstelle eine Falco-Regel, die erkennt, wenn in einem Container eine Shell geoeffnet wird."

# /etc/falco/rules.d/detect-shell.yaml
- rule: Shell Started in Container
  desc: Detect shell execution in a container
  condition: >
    evt.type=execve
    and container.id != host
    and proc.name in (bash, sh, zsh, dash)
  output: >
    Shell started in container
    (user=%user.name shell=%proc.name container=%container.name
    namespace=%k8s.ns.name pod=%k8s.pod.name)
  priority: WARNING
  tags: [container, shell]

3. AppArmor: Mandatory Access Control

AppArmor ist ein Linux-Security-Modul, das den Zugriff von Prozessen auf Systemressourcen einschraenkt. In der CKS muesst ihr Profile erstellen, laden und auf Pods anwenden koennen.

AppArmor-Profil erstellen

# Profil-Datei erstellen
# /etc/apparmor.d/k8s-restricted
cat << 'EOF' > /etc/apparmor.d/k8s-restricted
#include <tunables/global>

profile k8s-restricted flags=(attach_disconnected,mediate_deleted) {
  #include <abstractions/base>

  # Netzwerkzugriff erlauben
  network inet tcp,
  network inet udp,
  network inet icmp,

  # Dateizugriff einschraenken
  deny /etc/shadow r,
  deny /etc/passwd w,
  deny /proc/sys/** w,

  # Nur lesenden Zugriff auf /tmp
  /tmp/** r,

  # Schreibzugriff auf Log-Verzeichnis
  /var/log/** rw,

  # Alle anderen Dateien: lesen erlaubt
  /** r,
}
EOF

AppArmor-Profil laden und verwalten

# Profil laden
sudo apparmor_parser -r /etc/apparmor.d/k8s-restricted

# Geladene Profile anzeigen
sudo aa-status

# Profil im Enforce-Modus pruefen
sudo aa-status | grep k8s-restricted

# Profil entfernen
sudo apparmor_parser -R /etc/apparmor.d/k8s-restricted

Pod mit AppArmor-Profil

# Pod mit AppArmor-Annotation
apiVersion: v1
kind: Pod
metadata:
  name: apparmor-pod
  annotations:
    container.apparmor.security.beta.kubernetes.io/app: localhost/k8s-restricted
spec:
  containers:
    - name: app
      image: nginx:1.27

Wichtig fuer die Pruefung:

Das Profil muss auf dem Node geladen sein, auf dem der Pod laeuft.
Der Annotationsschluessel enthaelt den Container-Namen (app im Beispiel).
localhost/ ist das Praefix fuer lokal geladene Profile.

4. Seccomp: Syscall Filtering

Seccomp (Secure Computing) filtert Systemaufrufe, die ein Container ausfuehren darf. In der CKS muesst ihr Seccomp-Profile erstellen und auf Pods anwenden koennen.

Seccomp-Profil erstellen

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": [
    "SCMP_ARCH_X86_64",
    "SCMP_ARCH_X86",
    "SCMP_ARCH_AARCH64"
  ],
  "syscalls": [
    {
      "names": [
        "accept4",
        "bind",
        "clone",
        "close",
        "connect",
        "epoll_ctl",
        "epoll_wait",
        "exit",
        "exit_group",
        "fcntl",
        "fstat",
        "futex",
        "getpid",
        "listen",
        "mmap",
        "mprotect",
        "nanosleep",
        "openat",
        "read",
        "recvfrom",
        "sendto",
        "socket",
        "write"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Seccomp-Profil auf dem Node platzieren

# Standardpfad fuer Seccomp-Profile
sudo mkdir -p /var/lib/kubelet/seccomp/profiles

# Profil kopieren
sudo cp restricted.json /var/lib/kubelet/seccomp/profiles/restricted.json

Pod mit Seccomp-Profil

# Pod mit RuntimeDefault Seccomp-Profil (empfohlen)
apiVersion: v1
kind: Pod
metadata:
  name: seccomp-default
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: nginx:1.27

---
# Pod mit benutzerdefiniertem Seccomp-Profil
apiVersion: v1
kind: Pod
metadata:
  name: seccomp-custom
spec:
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/restricted.json
  containers:
    - name: app
      image: nginx:1.27

Pruefungstipp: RuntimeDefault reicht fuer die meisten Aufgaben. Ein benutzerdefiniertes Profil wird nur verlangt, wenn die Aufgabe es explizit fordert.

5. kube-bench: CIS Benchmark Checks

kube-bench prueft Kubernetes-Cluster gegen die CIS (Center for Internet Security) Benchmarks. In der CKS muesst ihr kube-bench ausfuehren und die Ergebnisse interpretieren koennen.

Installation und Ausfuehrung

# Als Container ausfuehren (empfohlen fuer die Pruefung)
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Ergebnisse anzeigen
kubectl logs job/kube-bench

# Direkte Ausfuehrung auf dem Node
kube-bench run --targets master
kube-bench run --targets node

# Nur fehlgeschlagene Checks anzeigen
kube-bench run --targets master | grep FAIL

Ergebnisse interpretieren

# Typische kube-bench-Ausgabe
# [PASS] 1.1.1 Ensure that the API server pod specification file permissions are set to 600
# [FAIL] 1.1.2 Ensure that the API server pod specification file ownership is set to root:root
# [WARN] 1.1.3 Ensure that the proxy kubeconfig file permissions are set to 600

# Fix fuer fehlgeschlagene Checks anwenden
# Beispiel: Datei-Berechtigungen korrigieren
sudo chmod 600 /etc/kubernetes/manifests/kube-apiserver.yaml
sudo chown root:root /etc/kubernetes/manifests/kube-apiserver.yaml

Typische CKS-Aufgabe

"Fuehre kube-bench auf dem Master-Node aus und behebe alle FAIL-Befunde fuer den API-Server."

# 1. kube-bench ausfuehren
kube-bench run --targets master --check 1.1

# 2. Fehlgeschlagene Checks identifizieren
kube-bench run --targets master --check 1.1 | grep FAIL

# 3. Remediation-Schritte ausfuehren (Beispiel)
sudo chmod 600 /etc/kubernetes/manifests/kube-apiserver.yaml
sudo chmod 600 /etc/kubernetes/manifests/kube-controller-manager.yaml
sudo chmod 600 /etc/kubernetes/manifests/kube-scheduler.yaml
sudo chmod 600 /etc/kubernetes/manifests/etcd.yaml

6. OPA Gatekeeper: Policy Enforcement

OPA Gatekeeper erzwingt Policies im Kubernetes-Cluster ueber Admission Control. In der CKS muesst ihr ConstraintTemplates und Constraints erstellen koennen.

Installation

# Gatekeeper via kubectl installieren
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/v3.16.0/deploy/gatekeeper.yaml

# Installation pruefen
kubectl get pods -n gatekeeper-system

ConstraintTemplate erstellen

# ConstraintTemplate: Container Images muessen aus erlaubter Registry stammen
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8sallowedrepos
spec:
  crd:
    spec:
      names:
        kind: K8sAllowedRepos
      validation:
        openAPIV3Schema:
          type: object
          properties:
            repos:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8sallowedrepos

        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          not startswith(container.image, input.parameters.repos[_])
          msg := sprintf("Container image '%v' is not from an allowed repository", [container.image])
        }

        violation[{"msg": msg}] {
          container := input.review.object.spec.initContainers[_]
          not startswith(container.image, input.parameters.repos[_])
          msg := sprintf("Init container image '%v' is not from an allowed repository", [container.image])
        }

Constraint erstellen

# Constraint: Nur Images aus der internen Registry erlauben
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces: ["production"]
  parameters:
    repos:
      - "registry.internal.example.com/"
      - "docker.io/library/"

Gatekeeper-Status pruefen

# Constraints auflisten
kubectl get constraints

# Violations pruefen
kubectl describe k8sallowedrepos allowed-repos

# Gatekeeper-Logs bei Problemen
kubectl logs -n gatekeeper-system deployment/gatekeeper-controller-manager

7. NetworkPolicies: Netzwerk-Segmentierung

NetworkPolicies sind ein Kernthema der CKS. Ihr muesst Default-Deny-Policies, Ingress-Rules und Egress-Rules sicher beherrschen.

Default Deny: Die Basis jeder Netzwerk-Segmentierung

# Default Deny All: Kein Traffic rein oder raus
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Gezielten Traffic erlauben

# Ingress: Nur Traffic von Frontend zu Backend erlauben
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

Egress-Policy: DNS und externe Services

# Egress: DNS und bestimmten externen Service erlauben
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-dns-and-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    # DNS erlauben (kube-dns / CoreDNS)
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
    # Zugriff auf externe API
    - to:
        - ipBlock:
            cidr: 203.0.113.0/24
      ports:
        - protocol: TCP
          port: 443

NetworkPolicies testen

# Test-Pods erstellen
kubectl run frontend --image=busybox -n production -l app=frontend -- sleep 3600
kubectl run backend --image=nginx -n production -l app=backend

# Connectivity testen
kubectl exec -n production frontend -- wget -qO---timeout=3 http://backend:80

# Wenn NetworkPolicy greift: Timeout
kubectl exec -n production frontend -- wget -qO---timeout=3 http://blocked-service:80
# Erwartung: wget: download timed out

Pruefungstipp: Vergesst nie, DNS in Egress-Policies zu erlauben. Ohne DNS-Zugriff koennen Pods keine Service-Namen aufloesen -- selbst wenn der Ziel-Traffic erlaubt ist.

Tool-Cheatsheet fuer die CKS-Pruefung

Hier die wichtigsten Befehle auf einen Blick:

# === TRIVY ===
trivy image --severity CRITICAL,HIGH nginx:1.27
trivy image --exit-code 1 --severity CRITICAL image:tag

# === FALCO ===
journalctl -u falco --no-pager | tail -50
cat /etc/falco/rules.d/custom-rules.yaml
sudo systemctl restart falco

# === APPARMOR ===
sudo apparmor_parser -r /etc/apparmor.d/profile-name
sudo aa-status
sudo apparmor_parser -R /etc/apparmor.d/profile-name

# === SECCOMP ===
# Profile liegen unter: /var/lib/kubelet/seccomp/profiles/
# Pod-Spec: securityContext.seccompProfile.type: Localhost
# Pod-Spec: securityContext.seccompProfile.localhostProfile: profiles/name.json

# === KUBE-BENCH ===
kube-bench run --targets master
kube-bench run --targets node
kube-bench run --targets master | grep FAIL

# === OPA GATEKEEPER ===
kubectl get constrainttemplates
kubectl get constraints
kubectl describe constraint-kind constraint-name

# === NETWORKPOLICIES ===
kubectl get networkpolicies -n namespace
kubectl describe networkpolicy policy-name -n namespace

Empfohlene Reihenfolge fuer die Vorbereitung

Woche 1-2: NetworkPolicies und RBAC (Grundlagen, die alles andere stuetzen)
Woche 3-4: Trivy und kube-bench (relativ einfach zu lernen, hohe Pruefungsrelevanz)
Woche 5-6: AppArmor und Seccomp (Linux-Security-Konzepte brauchen Zeit)
Woche 7-8: Falco und OPA Gatekeeper (die komplexesten Tools)
Woche 9-10: Integration und Pruefungssimulation mit killer.sh

Fuer einen detaillierten Lernplan empfehlen wir unseren CKA Lernplan als Basis, den ihr um die CKS-Themen erweitern koennt.

Haeufige Fehler bei der CKS-Tool-Vorbereitung

Nur Theorie gelernt. Jedes Tool muss praktisch geuebt werden. Lest nicht nur darueber -- installiert es und arbeitet damit.
AppArmor-Profile nicht auf dem richtigen Node. Das Profil muss auf dem Node geladen sein, auf dem der Pod scheduled wird. Prueft mit aa-status.
Seccomp-Pfad falsch. Der localhostProfile-Pfad ist relativ zu /var/lib/kubelet/seccomp/. Schreibt nicht den absoluten Pfad.
Falco-Regelsyntax. YAML-Einrueckung und die Rego-aehnliche Condition-Syntax muessen sitzen. Uebt das Schreiben von Regeln von Hand.
NetworkPolicy-DNS vergessen. Ohne Egress-Regel fuer Port 53 UDP/TCP funktioniert kein DNS -- und damit keine Service-Aufloesung.

Weitere Tipps zur Pruefungsvorbereitung findet ihr in unserem Artikel CKA Pruefung bestehen: 10 Tipps, der viele allgemeine Strategien abdeckt, die auch fuer die CKS gelten.

Fazit

Die CKS verlangt praktische Beherrschung von Security-Tools auf einem Niveau, das ueber reines Kubernetes-Wissen hinausgeht. Trivy, Falco, AppArmor, Seccomp, kube-bench, OPA Gatekeeper und NetworkPolicies sind die sieben Saeulen, auf denen die Pruefung steht.

Wer jedes dieser CKS Security Tools hands-on geuebt hat und die pruefungsrelevanten Befehle sicher beherrscht, ist fuer die CKS-Pruefung gut aufgestellt. Nutzt das Cheatsheet als Referenz und arbeitet jeden Abschnitt in einem eigenen Testcluster durch.

TL;DR

Warum Tool-Kenntnisse bei der CKS entscheiden

1. Trivy: Container Image Scanning

Installation

Pruefungsrelevante Befehle

Typische CKS-Aufgabe

2. Falco: Runtime Security Monitoring

Installation

Falco-Regeln verstehen

Pruefungsrelevante Befehle

Typische CKS-Aufgabe

3. AppArmor: Mandatory Access Control

AppArmor-Profil erstellen

AppArmor-Profil laden und verwalten

Pod mit AppArmor-Profil

4. Seccomp: Syscall Filtering

Seccomp-Profil erstellen

Seccomp-Profil auf dem Node platzieren

Pod mit Seccomp-Profil

5. kube-bench: CIS Benchmark Checks

Installation und Ausfuehrung

Ergebnisse interpretieren

Typische CKS-Aufgabe

6. OPA Gatekeeper: Policy Enforcement

Installation

ConstraintTemplate erstellen

Constraint erstellen

Gatekeeper-Status pruefen

7. NetworkPolicies: Netzwerk-Segmentierung

Default Deny: Die Basis jeder Netzwerk-Segmentierung

Gezielten Traffic erlauben

Egress-Policy: DNS und externe Services

NetworkPolicies testen

Tool-Cheatsheet fuer die CKS-Pruefung

Empfohlene Reihenfolge fuer die Vorbereitung

Haeufige Fehler bei der CKS-Tool-Vorbereitung

Fazit

Verwandte Artikel

Kubernetes-Beratung gesucht?

📖 Verwandte Artikel

CKS Prüfung: Kubernetes Security Specialist werden

Security Scanning automatisieren: Trivy und Falco CI/CD

CKS Zertifizierung: Kubernetes Security Specialist bestehen

Trivy, Falco und Kubescape im Vergleich

Falco: Runtime Security für Kubernetes-Cluster