Kubernetes absichern: Pod Security Admission, NetworkPolicies, OPA Gatekeeper und Runtime‑Scanning

Kubernetes absichern beginnt mit einer klaren Priorisierung: Netztrennung, Eintrittskontrolle bei Deployments und laufende Erkennung von Anomalien. In diesem Beitrag erkläre ich praxisnah, wie Sie Pod Security Admission (ein Kubernetes‑Admission‑Controller zur Durchsetzung von Pod‑Sicherheitsprofilen), NetworkPolicies (Netzwerksegmentierung im Cluster), OPA Gatekeeper (Policy‑Engine zur Admission‑Kontrolle) und Runtime‑Scanning (laufzeitnahe Erkennung von Angriffen und Fehlverhalten) zusammen einsetzen. Zielgruppe sind Administratoren, System Engineers und technische Dienstleister, die Betrieb, Migration und Absicherung verantworten.

Kubernetes absichern: Kernbausteine und Sicherheitsstrategie

Ein strukturierter Ansatz reduziert Risiken und Betriebsaufwand. Beginnen Sie mit einem einfachen, schrittweisen Schutzmodell:

• Härten der Pod‑Laufzeit (Pod Security Admission) – Regeln für Berechtigungen, Host‑Zugriffe, Capabilities.
• Netzwerk-Isolation (NetworkPolicies) – minimale Zugriffsflächen zwischen Services.
• Admission‑Kontrolle mit Policies (OPA Gatekeeper) – durchsetzbare Unternehmensregeln vor Persistenz.
• Runtime‑Detektion und Forensik – Agenten wie Falco oder eBPF‑Tools erfassen abweichendes Verhalten.

Diese Schichten ergänzen sich: PSA verhindert riskante Pods, NetworkPolicies begrenzen Lateralen Zugriff, Gatekeeper erzwingt organisatorische Vorgaben, und Runtime‑Scanner detektieren lebende Angriffe oder Fehlkonfigurationen.

Bedrohungsmodell und Betriebsannahmen

Vor technischen Maßnahmen muss klar sein, welche Risiken Sie adressieren. Typische Szenarien:

• Fehlerhafte Container‑Images mit Root‑Rechten.
• Seitliche Bewegung zwischen Pods durch offene Cluster‑Netzwerkregeln.
• Missconfigurations in Deployments (hostNetwork, hostPath, privileged).
• Exploit gegen Laufzeitprozesse, der Shell‑Exec in Containern ausführt.

Voraussetzungen für die folgenden Maßnahmen: Sie haben Cluster‑Admin‑Zugriff, Ihr CNI unterstützt NetworkPolicies (z. B. Calico, Cilium, Weave), und Sie haben Zugang zu CI/CD oder Image‑Registry‑Scans.

Pod Security Admission: Was es ist, wie es wirkt, typische Stolperfallen

Pod Security Admission (PSA) ist ein built‑in Admission Controller ab Kubernetes 1.22+, der Pod‑Sicherheitsprofile als Namespace‑Labels erzwingt. Profile sind vordefinierte Richtlinien wie „privileged“, „baseline“ und „restricted“. PSA wirkt beim Erstellen/Ändern von PodSpec: Es verhindert oder warnt bei Verstößen.

Warum PSA wirkt

PSA greift früh im Lebenszyklus einer Ressource (Admission), also bevor ein Pod im etcd persistiert wird. Es ist einfach zu konfigurieren und benötigt keine externe Komponenten. PSA reduziert risikoreiche Felder wie hostPath, privileged Container, bestimmte Capabilities oder Container‑User root.

Voraussetzungen und Risiken

PSA ist ein Muss, wenn Sie konsistente Minimalrechte durchsetzen möchten. Risiken: falsch konfigurierte Profile können Deployments brechen. Daher sollten Sie die Durchsetzung schrittweise (audit → warn → enforce) durchführen und eine Rollback‑Strategie haben.

Checkliste vor Aktivierung

• Identifizieren Sie kritische Namespaces und Starter‑Namespaces.
• Testen Sie Profile in einem Staging‑Cluster oder per „warn“ Mode.
• Dokumentieren Sie Ausnahmeregeln für spezielle Workloads (z. B. Node‑Agenten).

Beispiel: Namespace Label für „restricted“ (enforce)

Ein Label auf dem Namespace setzt das Profil. „enforce“ blockiert Verstöße.

kubectl label ns finance pod-security.kubernetes.io/enforce=restricted

Sie können vorher per „audit“ beobachten:

kubectl label ns staging pod-security.kubernetes.io/audit=baseline

Typische Fehlerszenarien

Häufige Stolperfallen sind Konfigurationen für DaemonSets/NodeAgents, die hostPath oder CAP_SYS_ADMIN benötigen. Pragmatismus hilft: Legen Sie Ausnahmesysteme in separaten Namespaces an, dokumentieren Sie die Gründe und konsolidieren Sie so die Angriffsfläche.

NetworkPolicies: Segmentierung in Kubernetes

NetworkPolicies regeln, welcher Pod welchen Pod erreichen darf. Wichtig: NetworkPolicies funktionieren nur, wenn das CNI diese unterstützt. Ohne NetworkPolicy ist intra‑Cluster‑Traffic standardmäßig frei (Allow all).

Prinzipien

Setzen Sie eine „deny by default“‑Haltung pro Namespace: Erlauben Sie nur notwendige Verbindungen (z. B. Frontend→Backend, Monitoring→Exporters). Das reduziert laterale Bewegung bei Kompromittierung.

Voraussetzungen

Prüfen Sie Ihr CNI:

kubectl get pods -n kube-system -o wide

Suchen Sie nach Calico, Cilium oder Weave‑Podnamen. Wenn Ihr CNI NetworkPolicy nicht unterstützt, müssen Sie CNI‑Wechsel einplanen oder ergänzende Netzwerkgeräte verwenden.

Beispiel: Default‑deny und gezielte Erlaubnis

Default‑deny für eingehenden Traffic im Namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: app
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Allow nur von frontend‑Pods zum backend‑Service:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: app
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

Prüfung und Debugging

Testen Sie Connectivity mit einem temporären Pod:

kubectl run --rm -it --image=busybox nettest -- /bin/sh
# im Pod
# telnet backend 8080 oder nc -zv backend 8080

Wenn Sie Connectivity erwarten und sie nicht vorhanden ist: Prüfen Sie NetworkPolicy Ressourcen, Labels und CNI‑Logs. Häufige Fehler: falsch gesetzte Labels, Namespaces nicht berücksichtigt oder Policies, die nur Ingress regeln, aber Egress zulassen müssen.

OPA Gatekeeper: Admission‑Policies zentral steuern

Open Policy Agent (OPA) ist eine generische Policy‑Engine; Gatekeeper ist ein Kubernetes‑Controller, der OPA als Admission Controller integriert. Mit Gatekeeper schreiben Sie firmenspezifische Regeln (Constraints), die vor Persistenz von Ressourcen geprüft werden.

Warum Gatekeeper ergänzend zu PSA und NetworkPolicies

PSA bietet vordefinierte Pod‑Sicherheitsprofile; Gatekeeper erlaubt flexible, organisationsspezifische Regeln (z. B. „Nur interne Registries zulässig“, „Keine hostPath für Non‑Ops Teams“). Gatekeeper kann auch Audits über bestehende Ressourcen laufen lassen.

Installation (kurz)

Gatekeeper lässt sich via Helm oder manifest installieren. Beispiel mit Helm:

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
helm install gatekeeper/gatekeeper --name-template gatekeeper --namespace gatekeeper --create-namespace

Beispiel: ConstraintTemplate und Constraint (kein komplettes Rego‑Tutorial)

ConstraintTemplate definiert das Schema; Constraint aktiviert die Regel mit Parametern. Beispiel: Verbieten von privileged: true in PodSpec.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8snoPrivileged
spec:
  crd:
    spec:
      names:
        kind: K8sNoPrivileged
  targets:
  - target: admission.k8s.gatekeeper.sh
    rego: |
      package k8snoPrivileged
      violation[{
        "msg": msg,
        "details": {"container": container_name}
      }] {
        input.review.object.spec.containers[_] as c
        c.securityContext.privileged == true
        container_name := c.name
        msg := sprintf("privileged container %v is not allowed", [container_name])
      }

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sNoPrivileged
metadata:
  name: disallow-privileged
spec:
  match:
    kinds:
    - apiGroups: ["" ]
      kinds: ["Pod"]

Wenn Gatekeeper eine Verletzung feststellt, wird die Admission abgelehnt und ein erklärender Fehler an den API‑User zurückgegeben.

Typische Betriebsfallen

Zu restriktive Rego‑Policies können CI/CD‑Pipelines brechen. Vorgehen: Testen Sie Policies lokal in einem Staging‑Cluster, verwenden Sie Gatekeeper Audit Mode (sucht Bestandsobjekte) und rollen Sie Policies schrittweise aus.

Runtime‑Scanning: Erkennung laufzeitnaher Bedrohungen

Runtime‑Scanning bezieht sich auf zwei Bereiche: statische Image‑Scans vor Deployment und Laufzeit‑Agenten, die auf dem Host Ereignisse überwachen. Beide sind wichtig: Image‑Scans (Trivy, Clair) finden bekannte CVEs; Laufzeit‑Agenten (Falco, eBPF‑Tools) entdecken abnormes Verhalten wie Shell‑Exec, ungewöhnliche Netzwerkverbindungen oder Schreibzugriffe auf sensiblen Pfaden.

Warum Laufzeit‑Erkennung nötig ist

Selbst geprüfte Images können Schwachstellen enthalten oder durch Fehlkonfigurationen exploitiert werden. Laufzeit‑Agenten liefern Echtzeit‑Erkennung und kontextreiche Alerts für Incident Response.

Beispiel: Image‑Scan mit Trivy

trivy image --severity HIGH,CRITICAL --ignore-unfixed myregistry.local/myapp:1.2.3

Ergebnis: Verwenden Sie die Ausgabe, um Builds zu blockieren oder Tickets im Ticketing‑System zu erzeugen.

Beispiel: Falco für Runtime‑Alerts

Falco überwacht Syscalls und kann in Kubernetes als DaemonSet installiert werden. Beispielregel (vereinfachter Ausschnitt), die execve in Containern alarmiert:

- rule: Detect Shell in Container
  desc: Shell executed in a container
  condition: evt.type = execve and container.id != host
  output: "Shell or suspicious exec in container (user=%user.name container=%container.name cmd=%proc.cmdline)"
  priority: WARNING

Installation via Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco --namespace falco --create-namespace

Integration in Überwachung und Incident Response

Senden Sie Falco‑Alerts an SIEM/Alertmanager/Slack. Definieren Sie Playbooks für typische Alerts (z. B. „exec in Produktionscontainer“): Containertask stoppen, Pod isolieren (NetworkPolicy ändern), Snapshot und Forensik‑Daten sichern.

Konkrete Umsetzungssequenz und Prüfplan

Empfohlene Reihenfolge für die Einführung im Produktivumfeld:

1. Baseline‑Analyse: Inventory aller Namespaces, Workloads, CNI‑Typ.
2. Pod Security Admission initial im audit‑Mode aktivieren. Sammeln Sie Verstöße.
3. Image‑Scanning in CI integrieren (Trivy) und fehlschlagende Builds markieren.
4. NetworkPolicies schrittweise von least privilege ausrollen (Start mit Nicht‑kritischen Namespaces).
5. Gatekeeper Policies entwickeln und im Audit‑Mode laufen lassen.
6. Falco oder vergleichbarer Runtime‑Agent als DaemonSet deployen, Alerts in SIEM integrieren.
7. Durchsetzung (PSA enforce, NetworkPolicies aktive deny, Gatekeeper enforce) und Monitoring stabilisieren.

Typische Prüfschritte

Führen Sie diese Prüfungen durch, bevor Sie Enforcement aktivieren:

• Liste der Pods mit riskanten Settings (privileged, hostPath):

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].securityContext.privileged==true) | {ns:.metadata.namespace, pod:.metadata.name}'

• Verifizieren Sie, dass NetworkPolicies gewünschte Verbindungen erlauben: temporäre Test‑Pods für connectivity checks.
• Gatekeeper Audit: Überprüfen Sie violations CRs, die Gatekeeper schreibt.

Rollback‑ und Notfallstrategie

Sicherheitssysteme können Betriebsabläufe beeinträchtigen. Planen Sie folgende Rückfallpfade:

• PSA: Entfernen des Namespace‑Labels schaltet Enforcement für den Namespace aus.
• NetworkPolicies: Ein Default‑deny kann per kubectl delete wieder aufgehoben werden; halten Sie eine temporäre „allow all“‑Policy bereit.
• Gatekeeper: Nutzen Sie kubectl patch/scale, um Gatekeeper kurz zu deaktivieren, wenn zwingend erforderlich (aber nur als letztes Mittel).
• Runtime‑Agent: Deaktivieren Sie Alerts vorübergehend, wenn sie Massen‑False‑Positives erzeugen, aber bewahren Sie Logs auf.

Notfall-Runbook (Kurzfassung)

1. Bei massiven Blockaden prüfen Sie Recent Audit‑Logs (PSA/Gatekeeper) und identifizieren die Policy.
2. Falls ein kritischer Job gestoppt ist: Entfernen Sie Namespace‑Label oder deaktivieren Sie einzelne Constraint‑Objekte temporär.
3. Kommunikation: Informieren Sie betroffene Teams, führen Sie Deploy‑Hotfix aus und dokumentieren Sie die Ursache.
4. Post‑Mortem: Policy anpassen, Tests erweitern, Change Control durchführen.

Betriebswissen, Troubleshooting und Best Practices

Pragmatische Tipps aus dem Betrieb:

• Versionierung: Policies (Gatekeeper ConstraintTemplates, NetworkPolicy YAMLs) wie Code im Git verwalten und per CI prüfen.
• Testing: Testen Sie Policies automatisiert gegen Referenz‑Workloads (Canary‑Namespace).
• Observability: Audit‑Logs, CNI Logs, Falco Alerts und kube‑audit zentral sammeln und correlaten.
• Least privilege: Starten Sie mit restriktiveren Defaults für neuere Namespaces; alt laufende Services behandeln Sie als Legacy mit dokumentierten Ausnahmen.
• Dokumentation: Notfallpfade, wer entzieht Labels oder deaktiviert Gatekeeper, und Change Approval sind betriebliche Muss‑Vorgaben.

Performance‑ und Skalierungsaspekte

Absicherung hat Kosten. PSA selbst verursacht kaum Latenz, da es leichtgewichtige Prüfungen durchführt. Gatekeeper hingegen führt Rego‑Evaluierungen bei jeder Admission aus; unter hoher Deploy‑Rate kann das zu Latenz oder CPU‑Last im API‑Pfad führen. Planen Sie daher Ressourcen‑Requests/Limits für Gatekeeper und beobachten Sie die API‑Server‑Latenz (kube‑apiserver‑Metric: apiserver_request_duration_seconds).

NetworkPolicies werden vom CNI umgesetzt: Calico kann iptables/ipsets oder eBPF nutzen; Cilium arbeitet nativ mit eBPF. eBPF‑basierte Enforcement‑Mechanismen haben in der Regel geringere Latenz und bessere Skalierung, kosten aber Kernel‑Unterstützung und eine aktuelle Distribution. Prüfen Sie CPU‑/Netz‑Performance vor und nach Rollout mit Lasttests auf Test‑Cluster.

Handling von False‑Positives und Regeln optimieren

False‑Positives sind ein Betriebsrisiko. Vorgehen:

1. Policy im Audit‑Mode laufen lassen und Violations sammeln.
2. Analysieren Sie Context (Pod, Benutzer, Image) und entscheiden dann: Regel anpassen oder explizite Ausnahme dokumentieren.
3. Regeländerungen testen in Staging, dann schrittweise promoten.

Beispiele zur Analyse von Falco‑Alerts: Ermitteln Sie das auslösende syscall‑Pattern, prüfen Sie die Prozess‑Kette mit kubectl logs und exec und ergänzen Sie die Falco‑Regel um Ausnahmekriterien statt Regeln global zu deaktivieren.

Host‑ und Hardware‑Betrieb: Kernel, eBPF und Ressourcen

Bei Runtime‑Schutz ist der Host wichtig: eBPF‑Tools benötigen Kernel‑Support (4.9+ mit eBPF‑Backports oder neuere Distributionen). Prüfen Sie Kernel‑Versionen und Module. Auf Hosts mit hoher Containerd‑Dichte sollten Sie auf I/O‑Limits achten, denn Forensik‑Snapshots können leistungsintensiv werden.

Praktischer Check: Kernel‑Version prüfen und eBPF‑Support validieren:

uname -r
# eBPF: prüfen ob bpftool vorhanden
bpftool version || echo "bpftool not installed"

Wenn eBPF fehlen sollte, planen Sie Kernel‑Updates oder alternative Agenten wie Falco im syscall‑Mode ein. Dokumentieren Sie die nötigen Host‑Packages und führen Sie Rolling‑Kernel‑Upgrades mit Live‑Kernel‑Strategie durch, um Ausfallzeiten zu vermeiden.

Audit‑Logging und Forensik: Was gesammelt werden sollte

Sammeln Sie folgende Artefakte für schnelle Reaktion und Post‑Mortem:

• kube‑apiserver Audit Logs (Audit‑Policy konfiguriert).
• CNI Logs und Netflow‑Spuren für laterale Bewegungen.
• Falco/Zabbix/Prometheus Alerts und vollständige Events mit Zeitstempel.
• Container Logs und ein Snapshot des betroffenen Filesystems.

Snapshot Beispiel: Erstellen Sie kontrolliert ein tar‑Archiv für Forensik (nur wenn Sie Speicher und I/O beachten):

kubectl exec -n ns pod -- tar -czf /tmp/fs-snapshot.tar.gz -C / --exclude=/proc --exclude=/sys --exclude=/dev
kubectl cp ns/pod:/tmp/fs-snapshot.tar.gz ./fs-snapshot.tar.gz

Bewahren Sie Snapshots sicher auf, signieren Sie Metadaten und halten Sie Korrelationen mit Timestamps bereit.

Kompatibilitäten und Integrationen

Wichtige Integrationspunkte, die Sie planen sollten:

• CI/CD: Image‑Scanning (Trivy) als Build‑Gate, Gatekeeper als Pre‑Apply Gate.
• Registries: Signierte Images und erlaubte Registry‑Listen via Gatekeeper erzwingen.
• Monitoring/SIEM: Falco → Alertmanager/SIEM, CNI‑Logs → Elastic/Kafka.
• Secrets‑Management: Vermeiden Sie direkte Secrets in Manifests; integrieren Sie ExternalSecrets/Vault.

Fazit: Pragmatismus vor Perfektion

Kubernetes absichern ist ein mehrschichtiger Prozess: Pod Security Admission, NetworkPolicies, OPA Gatekeeper und Runtime‑Scanning ergänzen sich. Wichtig ist eine schrittweise Einführung mit audit‑Phasen, automatisierten Tests und klaren Rollback‑Regeln. Priorisieren Sie Maßnahmen nach Angriffsfläche und Betriebsaufwand: Kleine Investments in PSA und NetworkPolicies liefern oft direkt spürbare Risikominderung; Gatekeeper und Runtime‑Scanner verbessern langfristig Governance und Detection.

Operationalisierung ist entscheidend: Versionierte Policies, Playbooks für Incidents, und überwachte Testzonen verhindern, dass Sicherheitsmaßnahmen den Betrieb beeinträchtigen. Planen Sie Performance‑Tests und Host‑Checks (Kernel, eBPF), bevor Sie eBPF‑abhängige Funktionen produktiv nutzen.

Weiterführende Prüfchecks (Kurzliste zum Mitnehmen)

• Kubectl: Prüfen Sie auf privilegierte Container, hostPath, hostNetwork.
• CNI: Support für NetworkPolicy bestätigen.
• CI: Image‑Scanner in Pipeline integrieren.
• Gatekeeper: Policies im Audit‑Mode laufen lassen, violations prüfen.
• Runtime: Falco oder eBPF‑Agent deployen und Alerts an SIEM routen.

Für dieses Thema sind auch Runtime-Scanning wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.