Sie beginnt, bevor ein Image gebaut wird, und läuft über Deployment, Betrieb, Incident Response und Außerbetriebnahme. Sie beschränkt sich nicht auf das Scannen eines Images auf bekannte Software-Schwachstellen.
Container bieten normalerweise Isolation auf Betriebssystemebene und teilen den Host-Kernel, anders als virtuelle Maschinen mit eigenen Gastkernels. Ihre Sicherheit hängt daher sowohl von der Container-Konfiguration als auch von der umgebenden Plattform ab. Ein privilegierter Container, ein gefährlicher Host-Mount, eine exponierte Orchestrator-API, eine kompromittierte Registry oder ein verwundbarer Knoten können sonst gut gebauten Anwendungscode unterlaufen.
Wichtigste Punkte
Die Lieferkette absichernMinimale, gepflegte Basis-Images verwenden, Abhängigkeiten pinnen und verifizieren, Build-Systeme und Registries schützen, Provenance erzeugen, Artefakte scannen und neu bauen, sobald Korrekturen verfügbar sind.
Deployment härtenAls Non-Root-Benutzer ausführen, unnötige Linux-Capabilities abgeben, Privilegieneskalation und Host-Zugriff einschränken, wo praktikabel schreibgeschützte Dateisysteme verwenden sowie Ressourcen- und Admission-Richtlinien durchsetzen.
Die Plattform schützenOrchestrator- und Knoten-Administration begrenzen, RBAC und Workload-Identitäten anwenden, Netzwerkpfade segmentieren, Secrets und Kontrollebenen-Daten schützen sowie Hosts und Laufzeitkomponenten gepatcht halten.
Überwachen und reagierenDeployment- und Audit-Ereignisse aufzeichnen, unerwartete Prozesse, Dateien, Verbindungen oder Privilegienänderungen erkennen, nützliche Nachweise sichern und kompromittierte Workloads aus vertrauenswürdigen Artefakten ersetzen.
Wichtige EinschränkungEin Container ist nicht automatisch eine starke Sicherheitsgrenze. Shared-Kernel-Schwächen, privilegierte Modi, schwache Richtlinien, exponierte Management-Schnittstellen oder unsichere Host-Integration können Ausbruch oder breitere Plattformkompromittierung ermöglichen.