Container-Plattformen absichern
Kubernetes gibt Ihrem Team viel Spielraum — und damit auch viele Möglichkeiten, bei der Security etwas falsch zu machen. Standardkonfigurationen sind selten sicher genug für den Produktionsbetrieb, und mit wachsenden Clustern wird die Lücke zwischen „es läuft" und „es ist gehärtet" oft still und leise größer.
Im Rahmen eines Container Platform Checks prüfe ich Ihr Plattform-Setup anhand von Security Best Practices. Die Prüfung umfasst:
- Container Capabilities
- Pod Specification Files & Configs
- Master Node Settings (API-Server, Controller Manager, Scheduler)
- Control Plane Configuration
- Worker Node & Kubelet Settings
- Encryption (Data-in-Transit & Data-at-Rest)
- Key Management
- Etcd Settings & Secret Management
- Pod Isolation (Namespace Isolation Policies)
- Ingress/Egress Routing
- RBAC Policies & Service Accounts
- Seccomp Profiles
- Logging & Monitoring
- DFIR-Readiness (Digital Forensics & Incident Response)
- Component & API Versions
Ich kombiniere die aktuellen CIS-Benchmark-Tests mit meiner Pentesting-Erfahrung in Container-basierten Umgebungen. Dadurch werden Findings nach realer Ausnutzbarkeit priorisiert — nicht nur nach Compliance-Checklisten.
Optional: Review von Container Images
Auf Wunsch kann dieser Plattform-Check auch die Container Images selbst abdecken. Ich analysiere sie anhand von Containerization Security Best Practices — mit Prüfung auf Fehlkonfigurationen, verwundbare Komponenten innerhalb der Images sowie die Art und Weise, wie diese Images gebaut und verteilt werden. Base-Image-Auswahl, Layer-Hygiene und ob Secrets versehentlich in eine Image-Schicht eingebrannt wurden, sind Teil dieser Analyse.
Optional: Container-Breakout-Testing
Ein Konfigurations-Review zeigt Ihnen, was theoretisch sicher sein sollte. Ein Breakout-Versuch zeigt, was es tatsächlich ist. Als optionale Erweiterung gehe ich über den Konfigurations-Review hinaus und versuche echte Container-Escapes gegen Ihr Setup — mit aktuellen Breakout-Techniken, um zu prüfen, ob ein Angreifer mit Code-Ausführung innerhalb eines Containers den Host, die Node oder andere Workloads erreichen kann.
Das umfasst unter anderem das Ausnutzen fehlkonfigurierter Capabilities, den Missbrauch gemounteter Service-Account-Tokens, Escapes über beschreibbare hostPath-Mounts und Tests, ob Ihre Pod Security Standards tatsächlich das stoppen, was sie stoppen sollen. Erfahrungsgemäß sind Teams oft überrascht, was nach einem vermeintlichen „Lockdown" auf dem Papier noch funktioniert.
Das Ziel ist kein vollständiger Pentest Ihrer Anwendungen — sondern eine gezielte Validierung Ihrer Container-Isolation. Wenn der Review Lücken in Ihrem Hardening findet, zeigt das Breakout-Testing, ob diese Lücken in der Praxis ausnutzbar sind oder nur theoretischer Natur.
Ergänzung: Review von Cloud-Umgebungen
Container-Orchestrierungsplattformen existieren selten isoliert — sie laufen typischerweise innerhalb von Cloud-Umgebungen wie AWS, Azure, GCP oder OTC. Die Cloud-Ebene bringt eigene Sicherheitsaspekte mit (IAM, Netzwerk, Storage-Sichtbarkeit), die mit der Container-Plattform-Konfiguration interagieren. Für das Review der umgebenden Cloud-Umgebung biete ich einen separaten Cloud Security Check an, der sich gut mit diesem Container Review kombinieren lässt.
Detailliertes Reporting
Der Ergebnisbericht der gefundenen Security-Probleme umfasst detaillierte Beschreibungen der Findings (inklusive aller gesammelten Nachweise) und konkrete Absicherungsempfehlungen pro Problem sowie Hinweise zur weiteren Härtung Ihrer Anwendung. Damit Findings schnell bei den richtigen Teams landen, kategorisiere ich sie nach Funktion (Business, Architektur, Entwicklung, Betrieb).
Nach Versand des Reports folgt ein Debriefing vor Ort oder remote, um Ergebnisse und offene Fragen gemeinsam mit den für die Behebung zuständigen Teammitgliedern durchzugehen.
Optional kann anschließend ein Re-Check der behobenen Findings erfolgen, der in einen aktualisierten Report mündet.
Voraussetzungen
Diese Art von Security-Check erfordert privilegierten Zugriff auf die Container-Plattform-Umgebung, um deren Sicherheit prüfen zu können. Zusätzlich wird Zugriff auf die Build- und Manifest-Dateien der Container benötigt, um das Container-Design aus Security-Sicht zu bewerten.
Hilfreich ist es außerdem, vorab einige Informationen zu Ihrer Architektur und zum gewünschten Container-Setup zu erhalten, damit das Review so zielgerichtet wie möglich erfolgen kann. Dazu gehören auch übergeordnete Informationen zu Ihrer Architektur: welche Komponenten eingesetzt werden und welche Art von Daten (in Bezug auf Sensitivität) auf welcher Komponente verarbeitet wird.
Diese Informationen werden üblicherweise in einem Kick-off-Workshop (remote oder vor Ort) bereitgestellt und besprochen, spätestens wenige Tage vor Beginn des Reviews.