Docker bewährte Verfahren für Sicherheit

Question

Die meisten Dockerfiles, die Sie im Internet finden, bauen und führen Software als root aus! Das sollte jeden beunruhigen, oder nicht? ... aber anscheinend ist das nicht der Fall ...

Das Problem ist also, dass das Ausführen eines Servers als root, selbst in einem Container, GEFÄHRLICH ist, weil root innerhalb eines Containers ziemlich das gleiche ist wie root außerhalb des Containers.

Eine Lösung besteht darin, ein Dockerfile ordnungsgemäß zu erstellen, indem die "USER" Anweisung wie in diesem Beispiel für ein Tor-Relais verwendet wird.

Eine andere Lösung besteht darin, die "Linux-Benutzernamensräume" zu verwenden, um die UID/GID innerhalb des Containers auf die UID/GID außerhalb eines Containers abzubilden. Zum Beispiel kann root (uid=0) innerhalb eines Containers auf Ihren persönlichen Benutzeraccount innerhalb des Hosts abgebildet werden, sodass Dateien, die in einem freigegebenen Volume erstellt werden, über die richtigen Berechtigungen verfügen.

Also meine Frage ist: Was ist die beste Praxis, wenn es um Sicherheit mit Docker geht? Code als Nicht-Root-Benutzer ausführen (d.h. "USER" Anweisung in einem Dockerfile verwenden)? Oder die Verwendung von "Benutzernamensräumen"? Oder gegebenenfalls (oder zusätzlich) die Verwendung von SELinux und/oder AppArmor?

Vielen Dank :)

Answer 1

Zitat Solomon Hykes

Hallo zusammen, ich bin ein Maintainer von Docker. Wie andere bereits angemerkt haben, funktioniert dies nicht auf Version 1.0. Aber es hätte funktionieren können.

Bitte denkt daran, dass wir zu diesem Zeitpunkt nicht behaupten, dass Docker out-of-the-box geeignet ist, um unvertrauenswürdige Programme mit Root-Rechten zu kontrollieren. Also, wenn ihr denkt "puh, gut dass wir auf 1.0 aktualisiert haben oder wir wären erledigt gewesen", müsst ihr jetzt eure zugrunde liegende Konfiguration ändern. Fügt AppArmor oder SELinux-Restriktionen hinzu, mappt vertrauenswürdige Gruppen auf separate Maschinen oder gewährt idealerweise keine Root-Zugriffe an die Anwendung.

Also, was bewährte Verfahren betrifft, ja zu den Namensräumen und zu AppArmor oder SELinux, wenn ihr es mit der Sicherheit ernst meint. Das gesagt haben viele Leute nicht genug Sorgfalt, um den zusätzlichen Aufwand zu betreiben (für besser oder schlechter), deshalb lassen viele Leute den zusätzlichen Aufwand sein. Die Berechtigungen für Benutzer auf Dateien innerhalb des Containers festzulegen (insbesondere auf solchen, die als Volumes gemountet sind) wird manchmal knifflig und deshalb überspringen viele Leute den Zusatzaufwand.

Answer 2

Zusätzlich zu SELinux, Apparmour, GRSEC, cgroups bietet den zusätzlichen Vorteil, die Ressourcennutzung des Containers zu isolieren und zu begrenzen. Wenn sorgfältig konfiguriert, hilft dies dabei, zu verhindern, dass ein kompromittierter Container einen anderen Container beeinflusst. Verweis

Answer 3

Die bewährte Methode besteht darin, alle drei am Ende der Frage genannten Optionen gemäß den CIS-Sicherheitsrichtlinien zusammen zu befolgen:

1. Benutzer ohne Root-Rechte im Container (Abschnitt 4.1)
2. Aktivieren von Benutzernamenräumen (Abschnitt 2.8)
3. Aktivieren von MAC, d.h. SELinux oder AppArmor im Erzwingungsmodus (Abschnitt 5.2)

Referenzen: https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.12.0_Benchmark_v1.0.0.pdf