Wie sich Container sicher mit Kubernetes orchestrieren lassen
Netzwerkverkehr standardmäßig untersagen
Des Weiteren müssen Cloud-Administratoren im Hinterkopf behalten, dass es keine Netzwerk-Policy für einen bestimmten Namensraum gibt. Die standardmäßige Policy erlaubt den Verkehr hin und von allen Pods in dem Namensraum.
Jeder Pod kann mit jedem anderen Pod kommunizieren. Wenn ein Angreifer also in einen öffentlich zugänglichen Pod eindringt, etwa mit einer Webanwendung, dann kann er diesen nutzen, um sich mit anderen Pods zu verbinden. Dies erleichtert Angreifern die laterale Bewegung nach dem Eindringen erheblich.
Best Practice hier besteht darin, den Zugang standardmäßig zu verbieten und Verkehr nur explizit zuzulassen. Daneben hat es sich bewährt, eine Kubernetes-Distribution einzusetzen, die nur wenige Optionen aber eine sichere Out-of-the-Box-Konfiguration mitbringt. RedHat OpenShift erfüllt beispielsweise diese Kriterien.
Angreifbare Anwendungen ausschließen
Auch auf Container-Ebene gibt es sicherheitsrelevante Aspekte, die schnell aus dem Blick geraten. So müssen Updates überall dort angewendet werden, wo sie benötigt werden, da jede Anwendung ihre eigene Kopie jeder Bibliothek hat. Dieselbe Bibliothek kann in mehreren Images aus verschiedenen Basis-Images installiert werden. Und diese müssen alle aktualisiert und mit Sicherheits-Patches versehen werden. Die Integration einer Lösung zum (automatischen) Aktualisieren in den DevOps-Prozess hilft an der Stelle weiter. Zumindest muss die Lösung sicherstellen, dass alle genutzten Container Images aktualisiert werden und aus vertrauenswürdigen Quellen stammen.
Es gab bereits Angriffe, die solche Images missbrauchten, so etwa für das Scannen nach angreifbaren Servern und Krypto-Mining. Für dieses Sicherheitsproblem liefert Docker eine Funktion namens „Content Trust“. Damit können Nutzer Images in einem Cluster oder Swarm zuverlässig bereitstellen und überprüfen, ob es sich tatsächlich um die von ihnen gewünschten Images handelt. Docker Content Trust (DCT) kann jedoch die Images nicht über den Swarm hinweg auf Veränderungen oder Ähnliches überwachen.
Im Kern ist DCT ein sehr einfaches Tool. Es geht um die Logik innerhalb des Docker-Clients, die Images verifizieren kann, welche Anwender von einem Registry-Server beziehen oder bereitstellen und die auf einem Docker Notary Server der Wahl signiert sind.
Container-spezifische, automatisierten Scanning-Technologien senken darüber hinaus die Gefahr, dass Anwendungen zum Angriffspunkt werden. Diese prüfen Images für Apps, die Teil des Continuous-Integration- und Continuous-Delivery (CI/CD)-Prozesses sind.
Ein Cluster ist nur so stark wie der schwächste Service
Releases erfolgen in Container-Umgebungen schnell, Architekturen werden kontinuierlich integriert und Softwareversionen regelmäßig aktualisiert. Herkömmliche Sicherheitsverfahren versagen. Aber die allgemeine Sicherheitsregel gilt auch hier, wonach ein Kubernetes-Cluster nur so sicher ist, wie der am schwächsten gesicherte Service, der darauf läuft. Unternehmen müssen deshalb ihre Sicherheit in Bezug auf unterschiedliche Komponenten der Containerarchitektur von den Containerlaufzeiten über Orchestratoren bis hin zu Entwicklungsumgebungen im Auge behalten und Sicherheitsmaßnahmen ableiten, die Master-Knoten, API-Server, etcd, Netzwerk-Policies und Anwendungen betreffen.
