Unsere Guidelines für Container Security

Container spielen bei DevOps-Strategien eine immer wichtigere Rolle - aber birgt das auch größere Risiken?

"Die geringe Einstiegshürde und Flexibilität von Container-Technologien sind gleichzeitig Segen und Fluch", erklärt Felix. Immer mehr Apps werden containerisiert und laufen problemlos – auch wenn sich Unternehmen kaum mit der sicheren Konfiguration beschäftigen. Besonders kritisch wird es dann, wenn verschiedene Applikationen ungesichert auf dem gleichen Host und in unterschiedlichen Umgebungen betrieben werden. „Das vergrößert die Angriffsfläche erheblich“, warnt Felix. Wie der einzelne Anwendungsfall auch gelagert ist, jede Applikation muss deshalb so konfiguriert sein, dass nur der Zugriff erhält, der auch wirklich berechtigt ist.

Felix und Anita haben das Gefühl, dass mit Containern oft zu leichtsinnig umgegangen wird. Angriffe können große Schäden verursachen. „Die häufigsten Angriffe zielen allerdings darauf ab, dass Crypto Bots automatisiert versuchen, Rechenpower zu klauen."

Bei cyan.it entwickelt das Team klare Guidelines für Container Security, um einen einheitlichen Standard zu schaffen. "Sicherheit ist immer ein Abwägen zwischen Nutzbarkeit und Absicherung", so Anita. "Unsere Empfehlungen sollen helfen, diesen Spagat zu meistern." 

Nicht-Root-Container-Benutzer

Wenn ein Docker-Container als Root-Benutzer ausgeführt wird, hat der Container dieselben Rechte wie der Root-Benutzer auf dem Hostsystem. Ein Beispiel für ein Sicherheitsrisiko: Ein böswilliger Benutzer könnte innerhalb des Containers bösartigen Code ausführen, um Zugriff auf kritische Verzeichnisse des Hosts zu erlangen, wie /etc/passwd oder /root, wo sensible Systeminformationen gespeichert sind. Er könnte auch auf andere Container zugreifen, das Netzwerk manipulieren oder zusätzliche Software installieren, etwa Tools für Krypto-Mining, wodurch das gesamte System kompromittiert wird.

Unveränderliche Container

Alle ausführbaren Codes und Scripte sollten bereits zur Build-Zeit des Containers festgelegt werden, um Sicherheit und Stabilität zu gewährleisten. Wenn Code erst zur Laufzeit von externen Quellen abgerufen wird, wie etwa ein Webserver-Container, der bei jedem Start Scripte von einem unbekannten Server lädt, entsteht ein erhebliches Risiko. Dieser nachträglich eingeführte Code wird nicht durch die ursprüngliche Qualitätssicherung überprüft und könnte Schwachstellen oder bösartige Inhalte enthalten. Durch die Bereitstellung aller nötigen Komponenten zur Build-Zeit wird verhindert, dass unkontrollierte Änderungen den Container gefährden.

Nur Daten im Docker-Verzeichnis mounten

Beim Mounten von Verzeichnissen in Docker wird das Dateisystem zwischen dem Host und dem Container geteilt, sodass beide auf dieselben Daten zugreifen können. Es sollte darauf geachtet werden, nur Daten aus bestimmten Docker-Verzeichnissen wie /var, /tmp, oder /opt zu nutzen, um potenzielle Sicherheitsrisiken zu minimieren. Sensible Verzeichnisse wie /etc, /root, oder /home sollten niemals gemountet werden, da sie vertrauliche Informationen enthalten können. Das Teilen des Dateisystems ermöglicht Lese- und Schreibzugriffe in beide Richtungen, was bei unsicheren Verzeichnissen zum Risiko ungewollter Datenlecks führt.

CI/CD-Server von Host-Servern trennen

Da der Docker-Daemon als Root läuft, hat jeder, der Zugriff auf diesen Daemon hat, die Möglichkeit, beliebigen Code mit Root-Rechten auszuführen. Um das Risiko zu minimieren, sollten CI/CD-Server von den Host-Servern getrennt werden. Wo möglich, sollte auf alternative Tools wie Podman Build oder Buildkit gewechselt werden, die sicherere Methoden zum Erstellen von Containern bieten.

Image-Scanning

Es ist entscheidend, Container-Images regelmäßig auf Schwachstellen zu scannen. Tools wie Renovate können dabei helfen, bekannte Sicherheitslücken in den verwendeten Abhängigkeiten zu erkennen und zu beheben, bevor diese in der Produktion eingesetzt werden.

Minimale Images verwenden

Um die Angriffsfläche zu minimieren, sollten Container-Images möglichst schlank gehalten und unnötige Pakete vermieden werden. Alpine-basierte Images, wie nginx, sind deutlich kleiner (ca. 20 MB) als das Standard-nginx-Image (über 100 MB), da sie nur die nötigsten Komponenten enthalten. Dadurch sinkt das Risiko von Sicherheitslücken, da weniger potenziell anfällige Software vorhanden ist

Digest statt Tags bei Docker-Containern verwenden

Statt Tags sollten Container-Images über ihren Digest referenziert werden, da dieser den genauen Zustand des Images garantiert. Ein Digest wird aus dem Image-Inhalt berechnet, sodass jede Änderung einen neuen Digest erzeugt, während Tags wie alpine/openssl:3.20.3 sich verschieben können und somit zu unerwarteten Änderungen führen. Indem man den Digest verwendet, stellt man sicher, dass immer das gleiche, überprüfte Image genutzt wird.

Ein Beispiel wäre die Nutzung dieser Referenz: alpine/openssl:3.20.3@sha256:beefdbd8a1da6d2915566fde36db9db0b524eb737fc57cd1367effd16dc0d06d statt nur alpine/openssl:3.20.3, um Konsistenz und Sicherheit zu gewährleisten.

Kontrollierter Traffic zwischen Containern

Es sollte darauf geachtet werden, dass nicht alle Container im Netzwerk beliebig miteinander kommunizieren können. Stattdessen sollten spezifische Netzwerke erstellt werden, die nur den notwendigen Traffic zwischen den Containern zulassen, um die Sicherheit zu erhöhen und die Möglichkeit von Seitwärtsbewegungen im Falle eines Angriffs zu minimieren.

Temporäres Dateisystem für zwischenspeichern von sensiblen Daten

tmpfs speichert Daten direkt im RAM, anstatt auf der Festplatte. Für Anwendungen wie Redis, die oft sensible Daten wie zum Beispiel Benutzerinformationen zwischenspeichern, ist das Ideal. Diese Daten bleiben im RAM und werden nicht auf das Hostsystem geschrieben, wo sie normalerweise auf Volumes zugänglich wären. Dadurch erhöht sich die Sicherheit, da diese sensiblen Informationen nicht auf dem Hostsystem gespeichert werden und beim Neustart automatisch gelöscht werden.

Drift Prevention und Laufzeitschutz (AppArmor)

Container-Drift beschreibt die Situation, in der ein laufender Container Code enthält, der nicht im ursprünglichen Image während des Builds enthalten war. Dies kann durch Angreifer ausgenutzt werden, um unerwünschten Code, wie beispielsweise für Krypto-Mining, in den Container einzuschleusen. Tools wie AppArmor können helfen, solche Veränderungen zu erkennen und zu verhindern, indem sie sicherstellen, dass nur spezifische, erlaubte ausführbare Dateien im Container verwendet werden dürfen.

Jetzt in Ihren Projekten für Sicherheit sorgen!

Sie wollen sicherstellen, dass bei Ihren Projekten Container Security professionell umgesetzt wird? Schreiben Sie uns eine Nachricht und lassen Sie uns über Ihre Fragestellungen sprechen! Anita und Felix stehen für einen Austausch zu allen Fragen der Container Security gerne zur Verfügung.