OWASP Docker Security Sheet - Versionsgeschichte

Thomas.will am 14. September 2025 um 08:32 Uhr

2025-09-14T08:32:47Z

Änderungen zeigen

Thomas.will am 14. April 2024 um 06:26 Uhr

2024-04-14T06:26:05Z

Thomas.will: /* REGEL #1 – Den Docker-Daemon-Socket nicht freigeben (auch nicht für die Container) */

2021-07-14T06:46:18Z

REGEL #1 – Den Docker-Daemon-Socket nicht freigeben (auch nicht für die Container)

Thomas.will: /* Verweise */

2021-07-13T18:09:12Z

Verweise

Thomas.will: /* Regel #11 – Linkt das Dockerfile zur Build-Zeit */

2021-07-13T18:08:51Z

Regel #11 – Linkt das Dockerfile zur Build-Zeit

Thomas.will: /* Regel #11 – Lint das Dockerfile zur Build-Zeit */

2021-07-13T18:07:54Z

Regel #11 – Lint das Dockerfile zur Build-Zeit

Thomas.will: /* REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen */

2021-07-13T18:07:01Z

REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen

Thomas.will: /* REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen */

2021-07-13T18:05:52Z

REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen

Thomas.will: /* REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen */

2021-07-13T18:05:22Z

REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen

Thomas.will: /* REGEL #5 – Deaktivieren der Kommunikation zwischen Containern (--icc=false) */

2021-07-13T18:04:16Z

REGEL #5 – Deaktivieren der Kommunikation zwischen Containern (--icc=false)

@@ Zeile 13: / Zeile 13: @@
 Außerdem teilen sich Container (im Gegensatz zu virtuellen Maschinen) den Kernel mit dem Host, daher treffen Kernel-Exploits, die innerhalb des Containers ausgeführt werden, direkt auf den Host-Kernel. Zum Beispiel führt ein Exploit zur Ausweitung von Kernel-Privilegien ( wie Dirty COW ), der in einem gut isolierten Container ausgeführt wird, zu Root-Zugriff auf einen Host.
-==REGEL #1 – Den Docker-Daemon-Socket nicht freigeben (auch nicht für die Container)==
+==REGEL 1 – Den Docker-Daemon-Socket nicht freigeben (auch nicht für die Container)==
 Docker-Socket /var/run/docker.sock ist der UNIX-Socket, auf den Docker lauscht. Dies ist der primäre Einstiegspunkt für die Docker-API. Der Besitzer dieses Sockets ist root. Jemandem Zugriff darauf zu gewähren, entspricht dem uneingeschränkten Root-Zugriff auf Ihren Host.
@@ Zeile 25: / Zeile 25: @@
 </syntaxhighlight>
-==REGEL #2 – Legen Sie einen Benutzer fest==
+==REGEL 2 – Legen Sie einen Benutzer fest==
 Die Konfiguration des Containers für die Verwendung eines nicht privilegierten Benutzers ist der beste Weg, um Angriffe auf eine Rechteausweitung zu verhindern. Dies kann auf drei verschiedene Arten wie folgt erreicht werden:
@@ Zeile 61: / Zeile 61: @@
 Als Kubernetes-Cluster-Administrator können Sie es mithilfe von Pod-Sicherheitsrichtlinien konfigurieren .
-==REGEL #3 – Beschränken Sie die Fähigkeiten (Gewähre nur bestimmte Fähigkeiten, die von einem Container benötigt werden)==
+==REGEL 3 – Beschränken Sie die Fähigkeiten (Gewähre nur bestimmte Fähigkeiten, die von einem Container benötigt werden)==
 Die Linux-Kernel-Fähigkeiten sind eine Reihe von Privilegien, die von Privilegierten verwendet werden können. Docker wird standardmäßig nur mit einer Teilmenge der Funktionen ausgeführt. Sie können es ändern und einige Funktionen löschen (mit '''--cap-drop'''), um Ihre Docker-Container zu härten, oder '''--cap-add''' bei Bedarf einige Funktionen hinzufügen (mit ). Denken Sie daran, keine Container mit dem '''--privileged''' Flag auszuführen - dies fügt dem Container ALLE Linux-Kernel-Funktionen hinzu.
@@ Zeile 93: / Zeile 93: @@
 Als Kubernetes-Cluster-Administrator können Sie es mithilfe von Pod-Sicherheitsrichtlinien konfigurieren .
-==REGEL #4 – Füge das Flag „no-new-privileges“ hinzu==
+==REGEL 4 – Füge das Flag „no-new-privileges“ hinzu==
 Führen Sie Ihre Docker-Images immer mit --security-opt=no-new-privilegesaus, um zu verhindern, dass Berechtigungen setuid oder setgid Binärdateien eskalieren.
@@ Zeile 116: / Zeile 116: @@
 Als Kubernetes-Cluster-Administrator können Sie die Kubernetes-Dokumentation zur Konfiguration mit Pod-Sicherheitsrichtlinien verwenden .
-==REGEL #5 – Deaktivieren der Kommunikation zwischen Containern (--icc=false)==
+==REGEL 5 – Deaktivieren der Kommunikation zwischen Containern (--icc=false)==
 Standardmäßig Inter-Container-Kommunikation (ICC) ist aktiviert - es bedeutet , dass alle Container miteinander (unter Verwendung sprechen können docker0 überbrückte Netzwerk ). Dies kann deaktiviert werden, indem der Docker-Daemon mit --icc=falseFlag ausgeführt wird. Wenn icc deaktiviert ist (icc=false), muss mit der Option --link=CONTAINER_NAME_or_ID:ALIAS mitgeteilt werden, welche Container kommunizieren können. Weitere Informationen finden Sie in der Docker-Dokumentation - Containerkommunikation
 In Kubernetes können Netzwerkrichtlinien dafür verwendet werden.
-==REGEL #6 – Linux-Sicherheitsmodul verwenden (seccomp, AppArmor oder SELinux)==
+==REGEL 6 – Linux-Sicherheitsmodul verwenden (seccomp, AppArmor oder SELinux)==
 Deaktivieren Sie zunächst nicht das Standardsicherheitsprofil!
@@ Zeile 128: / Zeile 128: @@
 Anweisungen dazu in Kubernetes finden Sie in der Dokumentation zum Sicherheitskontext und in der Kubernetes-API-Dokumentation
-==REGEL #7 – Ressourcen begrenzen (Speicher, CPU, Dateideskriptoren, Prozesse, Neustarts)==
+==REGEL 7 – Ressourcen begrenzen (Speicher, CPU, Dateideskriptoren, Prozesse, Neustarts)==
 Der beste Weg, um DoS-Angriffe zu vermeiden, besteht darin, die Ressourcen zu begrenzen. Sie können Speicher , CPU , maximale Anzahl von Neustarts ( --restart=on-failure:<number_of_restarts>), maximale Anzahl von Dateideskriptoren ( --ulimit nofile=<number>) und maximale Anzahl von Prozessen ( --ulimit nproc=<number>) begrenzen .
@@ Zeile 135: / Zeile 135: @@
 Sie können dies auch in Kubernetes tun: Zuweisen von Speicherressourcen zu Containern und Pods , Zuweisen von CPU-Ressourcen zu Containern und Pods und Zuweisen von erweiterten Ressourcen zu einem Container
-==REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen==
+==REGEL 8 - Dateisystem und Volumes auf schreibgeschützt setzen==
 Führen Sie Container mit einem schreibgeschützten Dateisystem mit '''--read-only''' Flag aus. Beispielsweise:
@@ Zeile 196: / Zeile 196: @@
 Standardmäßig ist der Docker-Daemon so konfiguriert, dass er einen Basis-Logging-Level von 'info' hat, und wenn dies nicht der Fall ist: Setzen Sie den Docker-Daemon-Log-Level auf 'info'. Begründung: Durch das Einrichten einer geeigneten Protokollebene wird der Docker-Daemon so konfiguriert, dass Ereignisse protokolliert werden, die Sie später überprüfen möchten. Eine Basisprotokollebene von 'info' und höher würde alle Protokolle außer den Debug-Protokollen erfassen. Solange dies nicht erforderlich ist, sollten Sie den Docker-Daemon nicht auf der Protokollebene 'debug' ausführen.
-=So konfigurieren Sie die Protokollebene in docker-compose=
+==Regel 11 – Linkt das Dockerfile zur Build-Zeit==
 Viele Probleme können verhindert werden, indem Sie beim Schreiben des Dockerfiles einige Best Practices befolgen. Das Hinzufügen eines Sicherheits-Linters als Schritt in der Build-Pipeline kann viel dazu beitragen, weitere Kopfschmerzen zu vermeiden. Einige Punkte, die es wert sind, überprüft zu werden, sind:
@@ Zeile 209: / Zeile 205: @@
 *Vermeiden Sie Curl-Bashing in '''RUN''' Direktiven
 =Links=
 https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

@@ Zeile 16: / Zeile 16: @@
 Docker-Socket /var/run/docker.sock ist der UNIX-Socket, auf den Docker lauscht. Dies ist der primäre Einstiegspunkt für die Docker-API. Der Besitzer dieses Sockets ist root. Jemandem Zugriff darauf zu gewähren, entspricht dem uneingeschränkten Root-Zugriff auf Ihren Host.
-Aktivieren Sie den TCP- Docker-Daemon-Socket nicht. Wenn Sie einen Docker-Daemon mit -H tcp://0.0.0.0:XXXoder ähnlichem ausführen, stellen Sie unverschlüsselten und nicht authentifizierten direkten Zugriff auf den Docker-Daemon bereit. Wenn Sie dies wirklich, wirklich tun müssen, sollten Sie es sichern. Überprüfen Sie anhand der offiziellen Docker-Dokumentation, wie das geht .
+Aktivieren Sie den TCP- Docker-Daemon-Socket nicht. Wenn Sie einen Docker-Daemon mit '''-H tcp://0.0.0.0:XXX''' oder ähnlichem ausführen, stellen Sie unverschlüsselten und nicht authentifizierten direkten Zugriff auf den Docker-Daemon bereit. Wenn Sie dies wirklich, wirklich tun müssen, sollten Sie es sichern. Überprüfen Sie anhand der offiziellen Docker-Dokumentation, wie das geht .
 Machen Sie /var/run/docker.sock nicht für andere Container verfügbar . Wenn Sie Ihr Docker-Image mit -v /var/run/docker.sock://var/run/docker.sockoder ähnlichem ausführen , sollten Sie es ändern. Denken Sie daran, dass das Mounten des Sockets schreibgeschützt keine Lösung ist, sondern nur die Ausnutzung erschwert. Äquivalent in der docker-compose-Datei ist etwa so:
@@ Zeile 24: / Zeile 24: @@
 - "/var/run/docker.sock:/var/run/docker.sock"
 </syntaxhighlight>
 ==REGEL #2 – Legen Sie einen Benutzer fest==
 Die Konfiguration des Containers für die Verwendung eines nicht privilegierten Benutzers ist der beste Weg, um Angriffe auf eine Rechteausweitung zu verhindern. Dies kann auf drei verschiedene Arten wie folgt erreicht werden:

@@ Zeile 208: / Zeile 208: @@
 *Vermeiden Sie Curl-Bashing in '''RUN''' Direktiven
 =Links=
 https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

@@ Zeile 202: / Zeile 202: @@
 Viele Probleme können verhindert werden, indem Sie beim Schreiben des Dockerfiles einige Best Practices befolgen. Das Hinzufügen eines Sicherheits-Linters als Schritt in der Build-Pipeline kann viel dazu beitragen, weitere Kopfschmerzen zu vermeiden. Einige Punkte, die es wert sind, überprüft zu werden, sind:
-*Stellen Sie sicher, dass eine USERA nweisung angegeben ist
+*Stellen Sie sicher, dass eine '''USER''' Anweisung angegeben ist
 *Stellen Sie sicher, dass die Basis-Image-Version angepinnt ist
 *Stellen Sie sicher, dass die Versionen der Betriebssystempakete angeheftet sind
-*Vermeiden Sie die Verwendung von ADD zugunsten von COPY
+*Vermeiden Sie die Verwendung von '''ADD''' zugunsten von '''COPY'''
-*Vermeiden Sie Curl-Bashing in RUN Direktiven
+*Vermeiden Sie Curl-Bashing in '''RUN''' Direktiven
 =Verweise=

@@ Zeile 199: / Zeile 199: @@
 docker-compose --log-level info up
-=Regel #11 – Lint das Dockerfile zur Build-Zeit=
+=Regel #11 – Linkt das Dockerfile zur Build-Zeit=
 Viele Probleme können verhindert werden, indem Sie beim Schreiben des Dockerfiles einige Best Practices befolgen. Das Hinzufügen eines Sicherheits-Linters als Schritt in der Build-Pipeline kann viel dazu beitragen, weitere Kopfschmerzen zu vermeiden. Einige Punkte, die es wert sind, überprüft zu werden, sind:

← Nächstältere Version		Version vom 13. Juli 2021, 18:07 Uhr
Zeile 171:		Zeile 171:
	</syntaxhighlight>		</syntaxhighlight>

−	Wenn das Volume nur zum Lesen gemountet ist, mounten Sie es außerdem schreibgeschützt. Dies kann durch Anhängen :~~roan~~ Folgendes erfolgen -v:	+	Wenn das Volume nur zum Lesen gemountet ist, mounten Sie es außerdem schreibgeschützt. Dies kann durch Anhängen ''':ro''' an Folgendes erfolgen '''-v:'''

← Nächstältere Version		Version vom 13. Juli 2021, 18:05 Uhr
Zeile 139:		Zeile 139:

	*docker run --read-only alpine sh -c 'echo "whatever" > /tmp'		*docker run --read-only alpine sh -c 'echo "whatever" > /tmp'
−	Wenn eine Anwendung in einem Container vorübergehend etwas speichern muss, kombinieren Sie --read-~~onlyFlag~~ mit --~~tmpfswie~~ folgt:	+	Wenn eine Anwendung in einem Container vorübergehend etwas speichern muss, kombinieren Sie '''--read-only''' Flag mit '''--tmpfs''' wie folgt:

← Nächstältere Version		Version vom 13. Juli 2021, 18:05 Uhr
Zeile 135:		Zeile 135:

	==REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen==		==REGEL #8 - Dateisystem und Volumes auf schreibgeschützt setzen==
−	Führen Sie Container mit einem schreibgeschützten Dateisystem mit --read-~~onlyFlag~~ aus. Beispielsweise:	+	Führen Sie Container mit einem schreibgeschützten Dateisystem mit '''--read-only''' Flag aus. Beispielsweise: