Container Security Grundlagen: Was jeder Kubernetes-Engineer wissen muss

Container Security ist kein Produkt, das man kauft. Es ist eine Reihe von Praktiken, die über den gesamten Container-Lebenszyklus hinweg angewendet werden – vom Dockerfile bis zum laufenden Pod in der Produktion.

Dieser Beitrag behandelt die Grundlagen, die ich mir gewünscht hätte, dass sie mir jemand klar erklärt hätte, als ich die Security-Rolle übernommen habe.

Die Angriffsfläche des Containers

#

Ein Container ist keine VM. Der Kernel wird zwischen dem Host und allen Containern auf diesem Node geteilt. Diese eine Tatsache verändert alles daran, wie man über Isolation nachdenkt.

Die Angriffsfläche hat vier Hauptschichten:

1. Das Image – Was zur Build-Zeit in den Container gebacken wurde (CVEs, fest kodierte Secrets, unnötige Pakete)
2. Die Runtime – Was der Container bei seiner Ausführung tun darf (Capabilities, Syscalls, Namespace-Escapes)
3. Die Orchestrierungsschicht – Was Kubernetes erlaubt (RBAC, Network Policies, Admission Controller)
4. Die Supply Chain – Woher das Image stammt und ob es manipuliert wurde

Jede Schicht braucht eigene Maßnahmen. Nur Images zu scannen ist keine Container Security.

Die wichtigsten Maßnahmen

#

1. Nicht als root ausführen

#

Das ist die wirkungsvollste Änderung mit minimalem Aufwand:

securityContext:
  runAsNonRoot: true
  runAsUser: 65534

Die meisten realen Container-Escapes erfordern, dass der Prozess als root (UID 0) im Container läuft. Lauf nicht als root.

2. Capabilities droppen

#

Linux Capabilities sind das feinkörnige Berechtigungssystem unterhalb von root. Die meisten Workloads brauchen keine davon:

securityContext:
  capabilities:
    drop:
      - ALL

Füge nur zurück, was wirklich gebraucht wird (z.B. NET_BIND_SERVICE für Ports < 1024).

3. Read-only Root-Dateisystem

#

Falls ein Angreifer Code-Ausführung erlangt, verhindert ein read-only Dateisystem das Ablegen von Payloads:

securityContext:
  readOnlyRootFilesystem: true

Binde beschreibbare emptyDir-Volumes nur für Pfade ein, die wirklich Schreibzugriff brauchen.

4. Images scannen, Policy durchsetzen

#

Trivy ist der De-facto-Standard für Image-Scanning. Aber Scannen allein bedeutet nichts ohne Durchsetzung. Nutze einen Admission Controller (OPA Gatekeeper oder Kyverno), um Pods zu blockieren, die deinen Schweregrad-Schwellenwert überschreiten:

trivy image --exit-code 1 --severity CRITICAL meinimage:latest

5. Images signieren und verifizieren

#

Nutze Cosign (Teil von Sigstore), um jedes Image in der CI zu signieren und Signaturen vor dem Deployment zu verifizieren. Das ist deine Verteidigung gegen Supply-Chain-Angriffe:

cosign sign --key cosign.key meinregistry/meinimage:v1.0.0
cosign verify --key cosign.pub meinregistry/meinimage:v1.0.0

Wo anfangen

#

Wenn du neu in der Container Security bist und priorisieren musst:

1. runAsNonRoot und readOnlyRootFilesystem cluster-weit über eine Kyverno/OPA-Policy durchsetzen
2. Trivy in deine CI-Pipeline einbauen
3. RBAC reviewen – die meisten Cluster sind überprivilegiert
4. Audit Logging aktivieren und verstehen, was in deinem Cluster passiert

Security ist iterativ. Warte nicht auf das perfekte Setup, bevor du anfängst.

Das ist der erste Beitrag einer Serie über Container Security Grundlagen. Als nächstes: Image Scanning im Detail mit Trivy und SBOM-Erstellung.