Eine unkomplizierte Docker-Sicherheits-Checkliste für die sicherheitsbewusste Entwickelnde

Warum sind Sie hier?

Sie möchten die echte Antwort auf zwei Fragen zur Docker-Sicherheit wissen:

Ist Docker sicher für den Produktionseinsatz?

Jaund nein. Docker verwendet ein Sicherheitsmodell, das auf Namespaces und Ressourcenisolierung basiert, wodurch die Prozesse innerhalb des Containers vor bestimmten Angriffen besser geschützt sind als bei der direkten Ausführung Ihrer Anwendungen auf einer Cloud-VM oder einem Bare-Metal-System. Trotz dieser Schutzschicht gibt es für Angreifer immer noch zahlreiche Möglichkeiten, auf Ihren container zuzugreifen, um vertrauliche Informationen auszulesen, Denial-of-Service-Angriffe (DoS) durchzuführen oder sogar Root-Zugriff auf das Host-System zu erlangen.

Wie kann ich meine Docker-Sicherheit verbessern (auf nicht allzu schmerzhafte Weise)?

Wirführen Sie durch die häufigsten und schwerwiegendsten Docker-Sicherheitslücken und überspringen dabei die grundlegenden Empfehlungen, die Sie überall bei Google finden, wie die Verwendung offizieller Images und die Aktualisierung Ihres Hosts. Stattdessen zeigen wir Ihnen direkt neue Docker-Optionen und Dockerfile-Zeilen, mit denen Sie Ihre neue Standard container sicherer denn je machen können.

Die „No-BS“-Docker-Sicherheits-Checkliste

container als schreibgeschützt festlegen

Was gewinnen Sie?

Sie verhindern, dass ein Angreifer die Laufzeitumgebung Ihres container bearbeitet, wodurch er nützliche Informationen über Ihre Infrastruktur sammeln, Benutzerdaten erfassen oder direkt einen DOS- oder Ransomware-Angriff durchführen könnte.

Wie richtet man es ein?

Sie haben zwei Optionen: entweder zur Laufzeit oder innerhalb Ihrer Docker Compose-Konfiguration.

Zur Laufzeit: docker run --read-only your-app:v1.0.1

In Ihrer Docker-Compose-Datei:

services:
webapp:
image: your-app:v1.0.1read_only: true
...

Rechteausweitung sperren

Was gewinnen Sie?

Sie verhindern, dass Ihr container– oder ein Angreifer, der sich in diesem containerzu schaffen macht – mit setuid oder setgid neue Berechtigungen, sogar auf Root-Ebene, aktiviert. Mit einem freizügigeren Zugriff auf Ihren container könnte ein Angreifer auf Anmeldedaten in Form von Passwörtern oder Schlüsseln für verbundene Teile Ihrer Bereitstellung, wie beispielsweise eine Datenbank, zugreifen.

Wie richtet man es ein?

Noch einmal, zur Laufzeit oder innerhalb Ihrer Docker Compose-Konfiguration.

Zur Laufzeit: docker run --security-opt=no-new-privileges your-app:v1.0.1

In Ihrer Docker-Compose-Datei:

services:  
	webapp:    
		image: your-app:v1.0.1    
		security_opt:      
			- no-new-privileges:true    
		...

Isolieren Sie Ihrecontainer

Was gewinnen Sie?

Standardmäßig lässt Docker alle Container über das Netzwerk „docker0“ kommunizieren, wodurch ein Angreifer möglicherweise lateral von einem kompromittierten container einem anderen wechseln kann. Wenn Sie über separate Dienste verfügen A und B in Containern Y und Z, und da sie nicht direkt kommunizieren müssen, bietet die Isolation ihrer Netzwerke dasselbe Endbenutzererlebnis und verhindert gleichzeitig laterale Bewegungen für eine verbesserte Docker-Sicherheit.

Wie richtet man es ein?

Sie können Docker-Netzwerke zur Laufzeit oder in Ihrer Docker Compose-Konfiguration angeben. Zuerst müssen Sie jedoch das Netzwerk erstellen:

docker network create your-isolated-network

Zur Laufzeit fügen Sie die --network Optionn: docker run --network your-isolated-network your-app:v1.0.1

Oder die entsprechende Option in Ihrer Docker Compose-Datei:

services:  
	webapp:    
    	image: your-app:v1.0.1    
        networks:      
        	- your-isolated-network    
		...

Einen geeigneten Nicht-Root-Benutzer festlegen

Was gewinnen Sie?

Der Standardbenutzer innerhalb eines container root, mit einer UID von 0. Durch die Angabe eines separaten Benutzers verhindern Sie, dass ein Angreifer seine Privilegien auf einen anderen Benutzer eskaliert, der ohne Einschränkungen agieren kann, wie z.B. Root, was alle anderen Docker-Sicherheitsmaßnahmen, die Sie mühsam implementiert haben, außer Kraft setzen würde.

Wie richtet man es ein?

Erstellen Sie Ihren Benutzer während des Build-Prozesses oder zur Laufzeit. Zur Laufzeit können Sie den Benutzer entweder zum ersten Mal erstellen oder den BENUTZER bereits beim Build festgelegt.

Während des Build-Prozesses, in Ihrem Dockerfile:

...
RUN groupadd -r your-user
RUN useradd -r -g your-user your-user
USER myuser
...

Zur Laufzeit: docker run -u your-user your-app:v1.0.1

Herabsetzen von Linux-Kernel-Capabilities

Was gewinnen Sie?

Standardmäßig dürfen Docker-Container einen eingeschränkten Satz von Linux-Kernel-Capabilities verwenden. Man könnte meinen, die Entwickler bei Docker hätten diesen eingeschränkten Satz so konzipiert, dass er vollständig sicher ist, doch viele Capabilities existieren aus Gründen der Kompatibilität und Einfachheit. Standard-Container können beispielsweise willkürlich Dateibesitzrechte ändern, ihr Root-Verzeichnis wechseln, Prozess-UIDs manipulieren und Sockets lesen. Durch das Entfernen einiger oder aller dieser Capabilities minimieren Sie die Anzahl der Angriffsvektoren.

Wie richtet man es ein?

Sie können Funktionen entfernen und während der Laufzeit neue festlegen. Beispielsweise könnten Sie alle Kernel-Funktionen entfernen und Ihrem container die Funktion zum Ändern der Eigentumsrechte bestehender Dateien gewähren.

docker run --cap-drop ALL --cap-add CHOWN your-app:v1.0.1

Oder für Docker Compose:

services:
	webapp:
    	image: your-app:v1.0.1
        cap_drop:
        	- ALL
        cap_add:
        	- CHOWN
        ...

Verhindert Fork-Bomben

Was gewinnen Sie?

Fork-Bomben sind eine Art von DoS-Angriff, bei dem ein bestehender Prozess unendlich oft repliziert wird. Zunächst verringern sie die Leistung und schränken die Ressourcen ein, was unweigerlich zu höheren Kosten führt und letztendlich zum Absturz Ihrer Container oder des Host-Systems führen kann. Sobald eine Fork-Bombe gestartet wurde, gibt es keine Möglichkeit, sie zu stoppen, außer den container den Host neu zu starten.

Wie richtet man es ein?

Zur Laufzeit können Sie die Anzahl der Prozesse (PIDs) begrenzen, die Ihr container erstellen container .

docker run --pids-limit 99 your-app:v1.0.1

Oder mit Docker Compose:

services:
	webapp:
		image: your-app:v1.0.1
		deploy
			limits:
				pids: 99

Verbessern Sie die Docker-Sicherheit durch Überwachung Ihrer Open-Source-Abhängigkeiten

Was gewinnen Sie?

Die Anwendungen, die Sie für die Bereitstellung mit Docker Containerisiert haben, haben wahrscheinlich einen breiten Abhängigkeitsbaum.

Wie richtet man es ein?

Der „unverfälschte“ Weg ist Scan von Softwareabhängigkeiten Open-Source Scan von Softwareabhängigkeiten Aikido. Unsere kontinuierliche Überwachung Projekte, die in mehr als einem Dutzend Sprachen geschrieben sind, basierend auf dem Vorhandensein von Lockfiles in Ihrer Anwendung und liefert einen sofortigen Überblick über Schwachstellen und Malware. Mit einer automatischen Triage, die Fehlalarme herausfiltert, Aikido Ihnen Aikido Empfehlungen zur Behebung, mit denen Sie sofort arbeiten können – und nicht erst, nachdem Sie ein Dutzend andere Referenzdokumente und GitHub-Issues gelesen haben.

Bei Aikido lieben wir etablierte Open-Source-Projekte wie Trivy, Syft und Grype. Aus Erfahrung wissen wir auch, dass ihre isolierte Verwendung keine besonders gute Entwicklererfahrung ist. Im Hintergrund Aikido diese Projekte mit benutzerdefinierten Regeln, um Lücken zu schließen und Sicherheitslücken aufzudecken, die Sie sonst nicht finden könnten. Im Gegensatz zur Verkettung verschiedener Open-Source-Tools Aikido Sie Aikido davon, ein Scan-Skript erstellen oder einen benutzerdefinierten Job in Ihrer CI/CD erstellen zu müssen.

Verwenden Sie nur vertrauenswürdige Images für die Docker-Sicherheit

Was gewinnen Sie?

Docker Content Trust (DCT) ist ein System zum Signieren und Validieren des Inhalts und der Integrität der offiziellen Images, die Sie aus Docker Registries wie Docker Hub ziehen. Das Ziehen nur von Images, die vom Autor signiert wurden, gibt Ihnen mehr Sicherheit, dass sie nicht manipuliert wurden, um Schwachstellen in Ihrem Deployment zu erzeugen.

Wie richtet man es ein?

Der einfachste Weg ist, die Umgebungsvariable in Ihrer Shell zu setzen, was Sie oder andere daran hindert, mit nicht vertrauenswürdigen Images zu arbeiten.

export DOCKER_CONTENT_TRUST=1
docker run ...

Oder Sie können die Umgebungsvariable jedes Mal setzen, wenn Sie Docker ausführen:

DOCKER_CONTENT_TRUST=1 docker run …

End-of-Life (EOL) Runtimes aktualisieren

Was gewinnen Sie?

Eine gängige Empfehlung für container lautet, Images und Abhängigkeiten an eine bestimmte Version zu binden, anstatt aktuellste. Theoretisch verhindert dies, dass Sie unwissentlich neue Images verwenden, selbst solche, die manipuliert wurden und neue Schwachstellen einführen.

Wie richtet man es ein?

Es gibt Open-Source-Projekte, die Ihnen helfen, EOLs zu entdecken und sich optimal vorzubereiten. Das Projekt endoflife.date (GitHub-Repository) verfolgt über 300 Produkte, indem es Daten aus mehreren Quellen aggregiert und über eine öffentliche API zur Verfügung stellt. Mit endoflife.date und ähnlichen Projekten haben Sie mehrere Optionen:

• Überprüfen Sie das Projekt manuell auf Updates für Abhängigkeiten, von denen Ihre Anwendungen abhängen, und erstellen Sie Tickets oder Issues für erforderliche Updates.
• Schreiben Sie ein Skript (Bash, Python usw.), um die EOL-Daten von Abhängigkeiten von der API abzurufen und führen Sie es regelmäßig aus, wie einen Cron-Job.
• Integrieren Sie die öffentliche API oder das benutzerdefinierte Skript in Ihre CI-Plattform, um Builds fehlschlagen zu lassen, die ein Projekt verwenden, das sich dem EOL nähert oder es erreicht hat.

Als Entwickler wissen wir, dass Ihre Zeit wertvoll und oft begrenzt ist. Hier Aikido Ihnen ein Gefühl der Sicherheit vermitteln – unsere EOL-Scan-Funktion verfolgt Ihren Code und Ihre Container und priorisiert Laufzeiten mit der größten Auswirkung und Exposition, wie Node.js oder einen Nginx-Webserver. Wie üblich automatisieren wir nicht nur die Erfassung von Informationen, sondern liefern auch Warnmeldungen mit angemessener Schwere, um Sie zu informieren, ohne Sie zu überfordern.

Begrenzung der container

Was gewinnen Sie?

Standardmäßig unterliegen Container keinen Ressourcenbeschränkungen und nutzen so viel Speicher oder CPU wie der Scheduler des Hosts. Durch die Begrenzung der Ressourcennutzung eines bestimmten container die Auswirkungen eines DoS-Angriffs minimiert werden. Anstatt Ihren container Ihr Host-System aufgrund einer Out-of-Memory-Ausnahme zum Absturz zu bringen, wirkt sich der andauernde DoS-Angriff „nur” negativ auf die Endbenutzererfahrung aus.

Wie richtet man es ein?

Zur Laufzeit können Sie die --memory und --cpus Option zum Festlegen von Grenzwerten für die Speicher- und CPU-Auslastung. Die Speicheroption akzeptiert Zahlen mit „g“ für Gigabyte und „m“ für Megabyte, während die CPU-Option den Grenzwert der für den container seine Prozesse verfügbaren dedizierten CPUs widerspiegelt.

docker run --memory="1g" --cpus="2" your-app:v1.0.1

Dies funktioniert auch mit Docker Compose:

services:
	webapp:
    	image: your-app:v1.0.1
        deploy:
            limits:
            	cpus: '2'
                memory: 1G
         ...

Ihre finalen Befehls- und Compose-Optionen für Docker-Sicherheit

Inzwischen haben Sie sicherlich einige Docker-Sicherheitstipps und die dazugehörigen CLI-Optionen oder Konfigurationen gesehen, was bedeutet, dass Sie entweder sehr gespannt sind, diese umzusetzen, oder überfordert damit, wie Sie alles zusammenfügen sollen. Im Folgenden haben wir alle Empfehlungen in einem einzigen Befehls- oder Konfigurations-Template zusammengefasst, das Ihnen hilft, sofort sicherere Docker-Container bereitzustellen.

Offensichtlich möchten Sie einige der Optionen ändern – wie den Namen des Nicht-Root-Benutzers, Kernel-Fähigkeiten, Ressourcenlimits – basierend auf den Anforderungen Ihrer Anwendung.

export DOCKER_CONTENT_TRUST=1
docker run \  
    --read-only \  
    --security-opt=no-new-privileges \  
    --network your-isolated-network \  
    --cap-drop ALL 
    --cap-add CHOWN \  
    --pids-limit 99 \  
    --memory="1g" --cpus="2" \  
    --user=your-user \  
    ...                 # OTHER OPTIONS GO HERE  
    your-app:v1.0.1

Sie möchten vielleicht sogar einen drun-Alias mit der Shell Ihres Hosts erstellen, den Sie aufrufen können, ohne sich all diese Details merken zu müssen.

function drun {  
docker run \   
    	--read-only \    
        --security-opt=no-new-privileges \    
        --network your-isolated-network \    
        --cap-drop ALL 
        --cap-add CHOWN \    
        --pids-limit 99 \    
        --memory="1g" --cpus="2" \    
        --user=your-user \    
        $1 \    
        $2
}

Führen Sie dann Ihren Alias wie folgt aus, mit Ihren Optionen und dem Image-Namen: drun -it your-app:v1.0.1

Wenn Sie ein Docker-Compose-Nutzer sind, können Sie all dieselben Optionen in ein neues Docker-Compose-Basistemplate übernehmen, das Sie zukünftig verwenden können:

services:
	webapp:
    	image: your-app:v1.0.1
        read_only: true
        security_opt:
           - no-new-privileges:true
        networks:
           - your-isolated-network
        cap_drop:
           - ALL
        cap_add:
           - CHOWN
        deploy:
        	limits:
        		pids: 9
        		cpus: '2'
        		memory: 1G
        ...               # OTHER OPTIONS GO HERE

Bonus: Docker mit rootless Containern ausführen

Wenn Sie Docker auf einem beliebigen System installieren, arbeitet dessen Daemon mit Root-Rechten. Selbst wenn Sie alle oben genannten Optionen aktivieren und eine Rechteausweitung innerhalb eines container verhindern, verfügt der Rest der container auf Ihrem Host-System weiterhin über Root-Rechte. Dies vergrößert zwangsläufig Ihre Angriffsfläche.

Die Lösung sind rootless Container, die von einem unprivilegierten Benutzer erstellt und verwaltet werden können. Der Verzicht auf Root-Rechte führt zu deutlich weniger Sicherheitsproblemen für Ihr Host-System.

Wir würden Ihnen gerne helfen, rootless Container mit einer einzigen Option oder einem Befehl zu nutzen, aber es ist leider nicht so einfach. Detaillierte Anweisungen finden Sie auf der Website für Rootless Container, einschließlich einer Anleitung für Docker.

Wie geht es weiter mit Ihrer Docker-Sicherheit?

​

Wenn Sie aus dieser Erfahrung etwas gelernt haben, dann ist es, dass container ein langwieriger Prozess ist. Es gibt immer mehr Checklisten zur Absicherung und ausführliche Artikel zum Thema Absicherung Ihrer Container in Docker oder dessen älterem und oft missverstandenem Verwandten Kubernetes. Sie können unmöglich container fehlerfreie container anstreben – wenn Sie sich in Ihrem vollen Entwicklungsplan Zeit für die Sicherheit nehmen und dann schrittweise Verbesserungen auf der Grundlage der Auswirkungen und Schwere vornehmen, werden Sie auf lange Sicht viel erreichen.

Um Ihnen dabei zu helfen, diesen kontinuierlichen Prozess zu optimieren und Korrekturen zu priorisieren, die die Sicherheit Ihrer Anwendung erheblich verbessern, gibt es Aikido. Wir haben gerade 17 Millionen US-Dollar in einer Serie-A-Finanzierungsrunde für unsere „No BS”-Entwickler-Sicherheitsplattform eingesammelt und würden uns freuen, wenn Sie sich uns anschließen würden.