Blog

Sicherheit wird im Docker-Ökosystem immer wichtiger

Sebastiaan van Steenis

Aktualisiert Oktober 22, 2025
4 Minuten

Sicherheit ist wahrscheinlich eines der größten Themen, wenn es um Container geht. Die Entwickler lieben Container, einige Mitarbeiter auch. Aber meistens läuft es auf die Sicherheitsaspekte von Containern hinaus. Ist die Nutzung sicher, was ist, wenn jemand ausbricht? Die Eigenschaften von Containern, die wir so lieben, können auch eine Schwachstelle sein, wenn es um die Sicherheit geht. In diesem Blog möchte ich einige gängige Methoden vorstellen, mit denen Sie Ihre Container in der Tiefe verteidigen können. Dies ist container-spezifisch, daher werde ich nicht über das Sperren der Host-Knoten oder die Reduzierung der Angriffsfläche z.B. durch das Deaktivieren von Linux-Daemons sprechen.

Nur-Lese-Container (Docker 1.5) Zunächst einmal die Möglichkeit, einen Nur-Lese-Container zu starten. Wenn Sie --read-only angeben, wird das Rootfs des Containers schreibgeschützt gemountet, so dass kein Prozess innerhalb des Containers darauf schreiben kann. Das heißt, wenn Sie in Ihrer Anwendung eine Schwachstelle haben, die das Hochladen von Dateien erlaubt, wird dies durch die Markierung des Container-Rootfs als schreibgeschützt verhindert. Dadurch wird auch verhindert, dass Anwendungen auf dem rootfs protokollieren, so dass Sie dafür einen entfernten Protokollierungsmechanismus oder ein Volume verwenden sollten. Verwendung(docs): $ docker run --read-only -v /icanwrite busybox touch /icanwrite here Benutzer-Namensräume (Experimentell) Viele Leute warten darauf, dass dieser Punkt in Stable landet. Derzeit bedeutet root im Container, dass Sie auch root auf dem Host sind. Wenn Sie in der Lage sind, /bin innerhalb Ihres Containers zu mounten, können Sie dort hinzufügen, was Sie wollen, und möglicherweise das Hostsystem übernehmen. Mit der Einführung von User-Namespaces werden Sie in der Lage sein, Container zu betreiben, in denen der Root-Benutzer innerhalb des Containers immer noch privilegierte Fähigkeiten hat, aber außerhalb des Containers wird die uid:gid auf einen nicht privilegierten Benutzer/Gruppe umgeschrieben. Dies ist auch bekannt als Phase 1, remapped root per Daemon-Instanz. Eine mögliche nächste Phase könnten vollständige Zuordnungen und Zuordnungen pro Container sein, aber das ist noch in der Diskussion. Verwendung(Dokumente): $ docker daemon --userns-remap=default Seccomp (Git Master Branch) Mit Namespaces haben wir eine Trennung, aber wir möchten auch kontrollieren, was innerhalb eines laufenden Containers passieren kann. Hier kommt seccomp ins Spiel. Seccomp ist die Abkürzung für Secure Computing Mode. Er ermöglicht es Ihnen, Syscalls zu filtern, d.h. Sie definieren die Syscalls, die Ihre Anwendung benötigt, und alle anderen werden verweigert. Ein kurzes Beispiel, gegeben socket.json: { "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "name": "socket", "action": "SCMP_ACT_ERRNO" } ] } führt zu Folgendem: # docker run -ti --rm --security-opt seccomp:tcpsocket.json ubuntu bash root@54fd6641a219:/# nc -l 555 nc: Operation not permitted Projekt Nautilus Eines der fehlenden Elemente im Ökosystem war die Überprüfung von Image-Inhalten. Die Aufregung war groß, als ein Artikel veröffentlicht wurde, in dem es hieß, dass über 30% der offiziellen Images im Docker Hub Sicherheitslücken aufweisen. Docker machte sich an die Arbeit und überprüfte viele offizielle Images im Hintergrund des Docker Hubs, bevor sie etwas darüber veröffentlichten. Während der Dockercon EU wurde Project Nautilus angekündigt, ein Image-Scanning-Service von Docker, der die Erstellung und den Konsum von hochintegrierten Inhalten vereinfacht. Es gibt noch nicht viel Offizielles über Nautilus, aber wir wissen, dass es im Hintergrund läuft und Docker sagt, dass sie damit über 74 Millionen Pulls gesichert haben. Kürzlich wurde eine Umfrage erstellt, in der Fragen zur Nutzung gestellt wurden, so dass ich Ihnen nur einige Vermutungen mitteilen kann. Zunächst einmal, was Docker laut eigenen Angaben tut:

  • Bildsicherheit
  • Verwaltung von Komponenteninventar/Lizenzen
  • Bildoptimierung
  • Grundlegende Funktionstests

Hier finden Sie einige Hinweise auf Dinge, die vielleicht bald kommen werden:

  • Nautilus vor Ort ausführen
  • Die Preisgestaltung kann pro Image oder pro installiertem Knoten erfolgen.
Nautilus

AppArmor-Profile Mit AppArmor können Sie Fähigkeiten mithilfe von Profilen einschränken. Die Profile können sehr feinkörnig sein, aber viele Leute wollen sich nicht die Zeit nehmen, diese Profile zu schreiben. Diese Profile können für laufende Docker-Container verwendet werden. Jessie Frazelle, einer der Hauptverantwortlichen für Docker, hat bane entwickelt, um das Schreiben dieser Profile zu vereinfachen. Es kann eine toml-Eingabedatei verwenden und generiert und installiert ein AppArmor-Profil. Dieses Profil kann dann bei der Ausführung eines Docker-Containers verwendet werden, und zwar in der gleichen Syntax wie zuvor beschrieben: docker run -d --security-opt="apparmor:name_of_profile" -p 80:80 nginx Docker Security Profiles Dies sind alles Teile, um Ihre Container zu sichern. Natürlich arbeitet Docker auch daran, dies so einfach wie möglich zu machen. Wenn Sie also mehr darüber wissen wollen, wie es weitergeht, sollten Sie sich den Vorschlag auf Github ansehen, um auf dem Laufenden zu bleiben.

Verfasst von

Sebastiaan van Steenis

Contact

Let’s discuss how we can support your journey.