Du willst Docker sicher nutzen?
Hier ist Deine Checkliste.
Starten wir
Alles zu Images
1. Vertrauenswürdige Images bevorzugen
Wenn Du nicht eigene Images baust, kannst Du schnell Opfer einer Supply Chain Attacke werden. Images, die nicht von einer offiziellen, verifizierten Quelle kommen, solltest Du nicht in Deiner Umgebung laufen lassen. Verwende möglichst nur Images, hinter welchen nur eine aktive Entwicklergruppe mit Problemlösern oder Unternehmen steht.
Exkurs Image-Tags und Irrglauben: Die meisten verwenden den Tag :latest, um das neuste Docker Image auszuwählen. Das stimmt so nicht. Du kannst ein Docker-Image bauen und jeden Tag verwenden, welchen Du willst z. B. :old-version. Du kannst alte Tags überschreiben und :latest nicht verwenden. Lese in der Docu nach, wie der Entwickler die Tags verwendet.
2. Minimale und unprivilegierte Images verwenden
Bei der Wahl des Images kannst Du noch mehr falsch machen.
Verwende eine minimales Basis OS wie Alpine Linux, welche viele Tools von einem normalen Desktop Distribution nicht mitbringt. Der Vorteil ist, dass sich die Angriffsfläche dadurch reduziert und der Hacker weniger Möglichkeiten hat, die Software im Docker Container auszunutzen. Außerdem sind die Imagegrößen kleiner, was die Installation beschleunigt.
3. Versionierung ernst nehmen und Rollbacks
Die Versionierung von Containern solltest Du wie bei einer echten Software nutzen.
Einen Release solltest Du nicht willkürlich auf verschiedene Tags puschen, sondern eine semantische Versionierung einhalten. Die Nutzer, welche das System in Produktion nutzen, sind dann vorsichtiger, wenn diese eine neue Haupt-Version einspielen.
Sichere Installation
4. Rootfreie Installationen verwenden
Docker ist keine normale Software, welche Du ohne weiteres ohne Root-Rechte laufen lassen kannst. Das Unternehmen bietet eine rootfreie Version Docker Rootless an, welche eine brauchbare Option für den laufenden Betrieb ist.
Die rootfreie Version limitiert einige Optionen. Normalerweise darf kein Nicht-Root-Programm eine Port zwischen 1 und 1024 öffnen, weil das System diese für die wohldefinierten Services reserviert. Des Weiteren sind einige Features in der rootfreien Version gar nicht verfügbar.
5. Kein Socket exposen oder mehere Instanzen
Der Docker-Socket ist für manche Programme notwendig, wie z. B. Portainer oder Jenkins. Diese steuern damit das Starten und Stoppen von Containern auf der Maschine.
Was super praktisch ist, ist auch eine große Gefahr.
Ein Container, der nicht vertrauenswürdig ist, hat Macht über alle anderen Container, wenn dieser Zugriff auf den Socket hat.
6. Sichere Grundlage
Ein aktualisiertes, gehärtetes Betriebssystem ist die Grundlage für eine sichere Nutzung von Docker.
Was bedeutet aktualisiert und gehärtet überhaupt?
Das Ziel ist es, dass alle Programme und Komponenten des Betriebssystems im Container mit allen Sicherheitspatches zu versorgen. Neue Features oder neue Hardware oder Performance sind hier nicht das Ziel (bzw. widersprechen zum Teil der Sicherheit).
Jedes Betriebssystem soll so stark kastriert sein, dass es ausschließlich die gewünschte Software laufen lassen kann. Jegliche andere Software kann nur eine Hilfe für einen Kriminellen sein.
Restriktionen forcieren
7. Ressourcen beschränken wie RAM und CPU
Du kannst die Ressourcen von einem Container auf Deinem Docker Host beschränken.
Dein System (Linux) hat in der Regel X GB an Arbeitsspeicher (RAM) und eine RAM-Datei (Swap) auf der Festplatte, die als Notfall-RAM dient.
Ein Angreifer greift an und macht den Container so ressourcen- hungrig, sodass alle anderen Programme auf dem Host nicht / kaum noch arbeiten können. Deshalb solltest Du den RAM limitieren.
Ich habe schon Images gesehen, welche nicht anständig mit Speicher umgehen und immer mehr Speicher konsumieren ohne den Speicher nach der Arbeit wieder abzugeben „Garbage-Collection“. Eine Systemüberlast verhinderst Du durch eine Limitierung.
8. Restarts auf 5 pro Minute reduzieren
Wenn alle Images gut laufen, dann braucht keiner ein Auffangnetz.
Leider kann durch eine Fehlkonfiguration oder ein Haupt-Update ein Container gar nicht mehr starten. In Kombination mit dem Befehl „restart: always“ landet der Container in einer ewigen Bootschleife.
Deshalb limitiere den Container auf 5 Starts in 60 Sekunden. Dann gibt das System auf. Idealerweise hast Du noch das alte Image (und einen Volume-Snapshot) bereit gelegt, um auf den alten Code-Stand zurückzugehen.
9. Nur Leserechte auf Volumes geben
Diese Volumes kannst Du mit Leserechte beschränken. Nicht jeder Container braucht volle Rechte auf jeden Ordner Deine Host-Dateisystems.
Patchen, Patchen, Patchen
10. Docker Container wie eine normales System patchen
Stelle Dir vor der Docker-Container ist ein eigener Computer. Wenn Du diesen baust kannst Du alle möglichen Abhängigkeiten importieren und verwenden, welche Dir zu einem Strick mutieren. Du musst sicher stellen, dass die aktuellsten Sicherheitspatches im Container installiert sind.
11. Scanner für Docker Images verwenden
Schlaue Entwickler kennen das Problem mit den Abhängigkeiten und haben deshalb einen Scanner entwickelt, welcher Dir die CVEs anzeigen lässt.
Damit musst Du nicht manuell nach den Schwachstellen suchen. Die Scanner ersetzen keinen Pentest, sind aber ein Muss für eine aktive Entwicklung.
12. Nicht Credentials frei nach außen publizieren
Das Dateisystem in Docker kann verwirrend sein. Verifiziere zweimal, dass Du nicht die Passwortdatei (.env) der Weltbevölkerung in Klartext präsentierst. Stattdessen ändere mit chmod am besten schon beim Bau des Docker Images. Alle Inhalte sollen die richtigen Rechte aufweisen.
Bitte nicht vergessen …
13. Backups von Volumes erstellen
Eine sehr sehr doofe Idee ist es, die Daten in einem Container zu speichern. Der Speicher ist weg, sobald der Container nicht mehr läuft.
Deshalb musst Du Docker-Volumes (automatische Verzeichnisse) oder eigene Verzeichnisse für die Speicherung von Daten ausweisen. Dies musst Du beim Start des Containers angeben.
14. Struktur ist Gold wert!
Ich verwende den Docker Run-Command fast gar nicht mehr.
Die Docker Compose ist ein möglicher Weg, wie Du strukturiert vorgehen kannst. Ein produktiver CLI-Commands mit allen Sicherheitsfeatures ist sehr lang und sollte deshalb in einer Compose-Datei gespeichert (persistiert) sein.
Du hast eine bessere Übersicht und kannst Änderungen in ein Git-Repo commiten. Jede Änderung der Compose-Datei kann Dir die Funktion zerstören. Ein Repo ist Dein Fangnetz.
15. Überlegen, ob Loadbalancing sinnvoll ist
Docker ist toll, aber keine Lösung für alle Probleme.
Ein Docker-Container kann nur so stark sein wie der Host selber. Deshalb verwende ein Container-Verwaltungssysteme wie Kubernetes. Diese System sind Quatsch, wenn Du nur eine Maschine hast. Die System bringen Module zur Lastverteilung mit sich . Ein Loadbalancer verteilt die Last auf die verschiedenen Container gleichmäßig.
