Was ist Container-Sicherheit?

Was ist Container-Sicherheit?

Container-Sicherheit bezeichnet den Schutz containerisierter Anwendungen und ihrer Umgebung über den gesamten Lebenszyklus: das gebaute Image, die Registry, die Orchestrierung, den laufenden Container und den darunterliegenden Host. Container teilen sich den Kernel des Hosts und werden häufig neu gebaut, deshalb zählen Image-Inhalt und Konfiguration mehr als die Härtung eines langlebigen Servers. Das NIST behandelt das Thema in SP 800-190, dem Application Container Security Guide.

Die fünf Ebenen

1. Images (Build-Zeit)

• Ein minimales Basis-Image verwenden, dann sind weniger Pakete zu patchen.
• Versionen festschreiben, am besten per Digest, statt latest zu nutzen.
• Images in der CI auf bekannte Schwachstellen scannen und den Build ab einer gewählten Schweregrad-Schwelle abbrechen.
• Als Nicht-Root-Benutzer laufen lassen und keine Secrets im Image ablegen.
• Images signieren und die Signatur vor dem Deployment prüfen.

2. Registry

• Eine private Registry mit Zugriffskontrolle und Audit-Logs nutzen.
• Gespeicherte Images erneut scannen, denn neue Schwachstellen werden nach dem Push bekannt.

3. Orchestrierung (Kubernetes)

• RBAC mit minimalen Rechten und ein eigenes Service-Konto pro Workload.
• NetworkPolicies, die Verkehr standardmäßig verbieten und nur erlauben, was jeder Pod braucht.
• Die Pod Security Standards von Kubernetes (Privileged, Baseline, Restricted) durchsetzen, für Anwendungs-Workloads bevorzugt Restricted.
• Admission Controller, die nicht konforme Manifeste ablehnen, und Audit-Logging am API-Server.
• Secrets über die Secret-API mit Verschlüsselung im Ruhezustand oder über einen externen Secrets-Manager.

4. Laufzeit

• Nicht benötigte Linux-Capabilities entfernen, ein schreibgeschütztes Root-Dateisystem nutzen, wo die Anwendung es erlaubt, und privilegierte Container vermeiden.
• Seccomp- und AppArmor- oder SELinux-Profile einsetzen, um Systemaufrufe einzuschränken.
• Auf auffälliges Verhalten achten, etwa eine Shell in einem Produktionscontainer oder unerwartete ausgehende Verbindungen.

5. Host

• Kernel und Container-Runtime patchen. Durch den gemeinsamen Kernel trifft eine Kernel-Lücke jeden Container auf dem Knoten.
• Ein minimales, auf Container ausgelegtes Host-Betriebssystem verwenden und direkte Logins einschränken.

Beispiel

Ein Team liefert einen Node-Dienst auf einem vollständigen OS-Basis-Image aus, als root, mit dem Tag latest und einem Datenbankpasswort in einer Umgebungsvariable. Mit einem schlanken, per Digest fixierten Image, Nicht-Root-Benutzer, schreibgeschütztem Dateisystem, zur Laufzeit eingebundenem Secret und einer Default-Deny-NetworkPolicy entfallen die meisten Wege, auf denen eine Lücke in einer Abhängigkeit zum Zugriff auf Datenbank oder Knoten wird.

Häufige Fehler

• Als root laufen, weil es der Image-Standard erlaubt.
• latest in Produktion ziehen, sodass ein Rebuild ohne Prüfung ändert, was läuft.
• Privilegierte Container, "damit es funktioniert", wodurch fast jede Isolation entfällt.
• Nur beim Build scannen und bereits ausgerollte Images nie erneut prüfen.
• Pod-zu-Pod- und ausgehenden Verkehr komplett offen lassen, sodass ein kompromittierter Pod alles erreicht.
• Ein breites Service-Konto für mehrere Workloads teilen.
• Cluster von Hand konfigurieren. Manifeste gehören in die Versionskontrolle und ins Review; siehe Infrastructure as Code.

Verwandte Konzepte

Die Aufteilung in Microservices vervielfacht die Zahl der Images und Netzwerkpfade, die abgesichert werden müssen. Zugriffe von Workloads und Menschen sollten den Prinzipien von Identity and Access Management folgen; was Angreifer versuchen, beschreibt der Eintrag zu Cyber-Sicherheitsbedrohungen.

Wo LoadFocus passt

LoadFocus ist kein Produkt für Container-Sicherheit: Es scannt keine Images, prüft keine Cluster-Konfiguration und erkennt keine Angriffe. Es hilft bei der Leistungsseite eines gehärteten Setups. Sidecars, mTLS, Policy-Engines und Runtime-Agenten kosten Latenz und CPU, und ein Lasttest zeigt, ob der Dienst sein Antwortzeitziel bei erwartetem Verkehr noch hält. API-Monitoring beobachtet danach Verfügbarkeit und Geschwindigkeit der Endpunkte nach jedem Deployment. Zur Praxis von Sicherheitstests in der Cloud siehe Best Practices für Sicherheit bei Cloud-Tests.

Häufige Fragen: Container-Sicherheit

Sind Container unsicherer als virtuelle Maschinen?

Sie isolieren anders. Container teilen den Host-Kernel, sodass eine Kernel-Lücke oder ein privilegierter Container den ganzen Knoten betreffen kann, während eine virtuelle Maschine einen eigenen Kernel hat. Container sind kleiner und leichter neu zu bauen und zu scannen. Beide können je nach Konfiguration sicher oder unsicher sein.

Was behebe ich zuerst?

Als Nicht-Root laufen, latest nicht mehr verwenden und Images in der CI scannen. Das ist günstig und beseitigt die häufigsten Probleme.

Brauche ich Laufzeit-Sicherheitswerkzeuge?

Scans zur Build-Zeit finden nur bekannte Schwachstellen. Laufzeiterkennung findet Verhalten, das Scans nicht sehen, etwa eine unerwartete Shell oder ausgehende Verbindung. Sie ist vor allem für sensible Produktionscluster wichtig.

Was leisten die Kubernetes Pod Security Standards?

Sie definieren drei Stufen: Privileged (unbeschränkt), Baseline (verhindert bekannte Rechteausweitungen) und Restricted (folgt aktueller Härtungspraxis für Pods). Pro Namespace wird eine Stufe durchgesetzt.

Löst Serverless-Container-Hosting das Problem?

Es verlagert Host- und Orchestrierungssicherheit zum Anbieter. Image-Inhalt, Secrets, Berechtigungen und Netzwerkregeln bleiben Ihre Aufgabe.