Container Security: Die häufigsten Fehler und wie Sie sie vermeiden

Warum ist Container Security anders als klassische Server-Sicherheit?

Container teilen sich den Kernel des Host-Systems. Anders als virtuelle Maschinen bringen sie keine eigene Betriebssystem-Isolation mit. Eine Schwachstelle im Kernel oder eine zu großzügig vergebene Berechtigung kann deshalb Auswirkungen über den einzelnen Container hinaus haben. 

Dazu kommen drei Besonderheiten: 

• Kurze Lebenszyklen: Container werden ständig neu erzeugt und ersetzt. Klassische Patch-Routinen auflaufenden Systemen greifen hier nicht. 
• Viele bewegliche Teile: Images, Registry, CI/CD-Pipeline, Cluster, Netzwerk jede Station ist ein potenzielles Einfallstor. 
• Geteilte Verantwortung: Entwicklung, Betrieb und Hosting-Partner müssen klar abgegrenzte Rollen haben. Wo diese Abgrenzung fehlt, fühlt sich am Ende niemand zuständig. 

Fehler 1: Container laufen mit Root-Rechten 

Der Standardfall in vielen Dockerfiles: Es wird kein eigener Benutzer definiert, der Prozess läuft als root. Gelingt einem Angreifer der Ausbruch aus dem Container oder findet er eine Schwachstelle in der Anwendung, arbeitet er direkt mit maximalen Rechten weiter. So vermeiden Sie ihn: 

• Legen Sie im Dockerfile einen unprivilegierten Benutzer an und setzen Sie ihn per USER-Anweisung. 
• Erzwingen Sie im Cluster über den Security Context, dass Container nicht als root starten (runAsNonRoot). 
• Setzen Sie allowPrivilegeEscalation auf false und entfernen Sie nicht benötigte Linux Capabilities. 
• Verzichten Sie auf privilegierte Container. Wenn ein Workload sie wirklich benötigt, sollte das eine dokumentierte Ausnahme mit Begründung sein. 

Fehler 2: Veraltete oder unbekannte Base Images 

Ein Image enthält immer den Patch-Stand seines Build-Zeitpunkts. Wird es nie neu gebaut, wandern bekannte Schwachstellen mit jedem Deployment erneut in die Produktion. Besonders kritisch: Images aus öffentlichen Quellen, deren Herkunft niemand im Team benennen kann. So vermeiden Sie ihn: 

• Verwenden Sie schlanke, offizielle Base Images. Weniger Pakete bedeuten weniger Angriffsfläche. 
• Integrieren Sie einen Schwachstellen-Scan (etwa Trivy oder Grype) fest in die CI/CD-Pipeline und definieren Sie, ab welchem Schweregrad ein Build abbricht. 
• Bauen Sie Images regelmäßig neu, auch ohne Codeänderung. Ein wöchentlicher Rebuild ist ein einfacher, wirkungsvoller Hebel. 
• Führen Sie eine Software Bill of Materials (SBOM), damit Sie bei einer neuen CVE innerhalb von Minuten wissen, ob Sie betroffen sind. 

Fehler 3: Secrets im Image oder im Repository

Datenbank-Passwörter, API-Keys oder Zertifikate landen erstaunlich häufig direkt im Dockerfile, in einer. env-Datei im Image oder als Klartext in einem YAML-Manifest im Git-Repository. Einmal committet, bleiben sie in der Historie auch nach dem Löschen. So vermeiden Sie ihn: 

• Trennen Sie Konfiguration konsequent vom Image. Secrets gehören zur Laufzeit hinein, nicht zum Build. 
• Nutzen Sie Kubernetes Secrets mit aktivierter Verschlüsselung im etcd oder eine externe Lösung wie HashiCorp Vault beziehungsweise den External Secrets Operator. 
• Setzen Sie bei GitOps auf Sealed Secrets oder SOPS, damit verschlüsselte Werte versioniert werden können. 
• Prüfen Sie Repositories automatisiert auf Secrets (Secret Scanning) und rotieren Sie kompromittierte Zugangsdaten sofort. 

Fehler 4: Der latest-Tag in der Produktion

image: shop:latest wirkt praktisch, macht Deployments aber unvorhersehbar. Sie wissen nicht sicher, welcher Stand läuft, Rollbacks werden zum Ratespiel und ein manipuliertes Image fällt möglicherweise gar nicht auf. So vermeiden Sie ihn: 

• Arbeiten Sie mit eindeutigen Versions-Tags, idealerweise mit dem Image-Digest (sha256). 
• Setzen Sie imagePullPolicy bewusst und nachvollziehbar. 
• Signieren Sie Images (etwa mit Cosign) und lassen Sie den Cluster nur signierte Images aus Ihrer eigenen Registry annehmen. 

Fehler 5: Keine Netzwerksegmentierung im Cluster 

In einem frisch aufgesetzten Kubernetes-Cluster darf standardmäßig jeder Pod mit jedem anderen Pod sprechen über alle Namespaces hinweg. Ein kompromittierter Frontend-Container hat damit freie Sicht auf Datenbank, Cache und interne Services. So vermeiden Sie ihn: 

• Definieren Sie NetworkPolicies nach dem Prinzip „default deny“ und geben Sie nur benötigte Verbindungen frei. 
• Trennen Sie Umgebungen und Mandanten sauber über Namespaces. 
• Beschränken Sie ausgehenden Traffic (Egress). Viele Angriffe scheitern daran, dass Schadcode keine Verbindung nach außen aufbauen kann. 

Fehler 6: Zu weitreichende Berechtigungen (RBAC)

Der Weg des geringsten Widerstands heißt cluster-admin. Er funktioniert immer und macht jede spätere Kompromittierung maximal teuer. Ähnlich problematisch: der automatisch eingebundene Default-ServiceAccount-Token in jedem Pod. 

So vermeiden Sie ihn: 

• Vergeben Sie Rechte nach dem Least-Privilege-Prinzip, bevorzugt über Roles statt ClusterRoles. 
• Deaktivieren Sie automountServiceAccountToken, wo der Pod die API gar nicht benötigt. 
• Prüfen Sie Berechtigungen regelmäßig und dokumentieren Sie, wer warum welchen Zugriff hat. 
• Nutzen Sie getrennte Zugänge für Menschen und Maschinen, mit Multi-Faktor-Authentifizierung für administrative Zugriffe. 

Fehler 7: Fehlende Ressourcenlimits

Ohne requests und limits kann ein einzelner Container Arbeitsspeicher oder CPU eines ganzen Nodes belegen. Das ist zunächst ein Stabilitätsthema wird aber zum Sicherheitsthema, sobald jemand diesen Effekt gezielt auslöst. Für Online-Shops bedeutet das im schlechtesten Fall: Ausfall zur besten Verkaufszeit. 

So vermeiden Sie ihn: 

• Definieren Sie für jeden Workload realistische requests und limits. 
• Setzen Sie ResourceQuotas und LimitRanges pro Namespace. 
• Testen Sie das Verhalten unter Last, bevor die nächste Kampagne startet. 

Fehler 8: Keine Sichtbarkeit zur Laufzeit 

Viele Teams sichern den Build-Prozess ordentlich ab und wissen dann nicht, was im laufenden Cluster passiert. Ohne zentrale Logs, Metriken und Audit-Trail bleibt ein Vorfall unentdeckt, bis Kunden ihn melden. 

So vermeiden Sie ihn: 

• Aktivieren Sie das Kubernetes Audit Logging und speichern Sie Logs revisionssicher außerhalb des Clusters. 
• Setzen Sie auf zentrales Monitoring und Alerting mit klar definierten Schwellwerten. 
• Ergänzen Sie Runtime-Security (etwa Falco), um verdächtiges Verhalten wie unerwartete Shell-Zugriffe zu erkennen. 
• Legen Sie fest, wer im Ernstfall informiert wird, und welche Schritte folgen. Ein Incident-Response-Plan, den niemand kennt, hilft nicht. 

Fehler 9: Der Cluster selbst wird vergessen

Die Control Plane, der API-Server, etcd und die Node-Betriebssysteme brauchen ebenso Pflege wie die Anwendungen darauf. Ein öffentlich erreichbarer API-Server ohne saubere Authentifizierung ist eine offene Tür. Auch fehlende Backups des Cluster-States gehören in diese Kategorie – Verfügbarkeit ist Teil von Sicherheit. 

So vermeiden Sie ihn: 

• Beschränken Sie den Zugriff auf den API-Server auf definierte Netze. 
• Verschlüsseln Sie etcd und sichern Sie es regelmäßig. 
• Etablieren Sie einen verbindlichen Update-Prozess für Kubernetes-Versionen und Node-Images. 
• Testen Sie Restores. Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, keine Absicherung. 

Fehler 10: Compliance wird nachgelagert betrachtet 

Wo personenbezogene Daten verarbeitet werden – und in einem Online-Shop ist das der Normalfall ist Container Security auch eine DSGVO-Frage. Standort der Daten, Auftragsverarbeitung, Protokollierung von Zugriffen und Löschkonzepte lassen sich nur schwer nachträglich in eine gewachsene Plattform einbauen. 

So vermeiden Sie ihn: 

• Klären Sie Serverstandort und Auftragsverarbeitungsvertrag früh mit Ihrem Hosting-Partner. 
• Dokumentieren Sie Datenflüsse zwischen Services, inklusive externer Schnittstellen. 
• Definieren Sie Aufbewahrungsfristen für Logs, die auch tatsächlich technisch umgesetzt werden. 

Checkliste: Container Security in zehn Punkten 

1. Container laufen unprivilegiert, nicht als root. 
2. Base Images sind schlank, aktuell und werden regelmäßig neu gebaut. 
3. Image-Scanning ist fester Bestandteil der Pipeline. 
4. Secrets liegen außerhalb von Image und Repository. 
5. Images sind versioniert und signiert. 
6. NetworkPolicies folgen dem Prinzip „default deny“. 
7. RBAC ist nach Least Privilege konfiguriert und dokumentiert. 
8. Jeder Workload hat Ressourcenlimits. 
9. Logging, Monitoring und Runtime-Security sind aktiv. 
10. Cluster-Updates, Backups und Restores sind erprobte Routine. 

Kubernetes sicher betreiben mit einem Partner, der mitdenkt 

Container Security ist kein einmaliges Projekt, sondern Betriebsarbeit. Mit Kubernetes ONE erhalten Sie eine gemanagte Kubernetes-Plattform aus deutschen Rechenzentren, bei der Härtung, Updates und Monitoring der Plattform in unserer Verantwortung liegen während Sie die volle Kontrolle über Ihre Workloads behalten. 

Ihre Kubernetes-Plattform mit voller Kontrolle.