Härten / Reduzieren der Angriffsfläche für einen Docker-Container

Ich möchte eine gehärtete Docker-Instanz einrichten, hauptsächlich zum Ausführen von Mikrodiensten wie statisch kompilierten Golang-Anwendungen. Was ich suche, ist, das Host-Betriebssystem vor einem betrügerischen Container und Container voreinander zu schützen. Ich habe versucht, die Situation mit dem folgenden Szenario zusammenzufassen.

Szenario :

Wir haben einen Server mit einem minimalen Betriebssystem wie Alpine Linux (Busybox-basiertes Betriebssystem), auf dem SElinux und grsec installiert, aktiviert und korrekt konfiguriert sind.

Auf diesem Server wird eine Docker-Instanz mit 2 laufenden Containern A und B und einem Volume V ausgeführt.

Der Container A enthält eine statisch kompilierte Anwendung ohne Abhängigkeiten, die mit dem öffentlichen Internet (Web-App oder öffentliche API) vernetzt ist. Diese Anwendung enthält einen RIESIGEN Fehler wie die Ausführung von willkürlichem Code/Upload/Full Reverse Shell, je schlimmer Sie sich vorstellen können. Dieser Container ist auch mit dem Volume V als Upload-Ziel, Datenbank usw. vernetzt.

Das Host-Betriebssystem enthält ein Flag, das nur gelesen werden kann, wenn root (von SElinux erzwungen).

Der Container B enthält auch ein Flag und eine Anwendung, aber keine Verbindung zur Außenwelt.

Angreifer :

• Mensch, kennt den großen Fehler in der Anwendung.
• Er will die Fahnen bekommen. Die Daten in V sind nicht wichtig.
• Er ist keine Spionageagentur, aber dennoch ein hochrangiger Sicherheitsspezialist.
• Möglicherweise haben Sie Zugriff auf einige Zero-Days, die uns nicht bekannt sind.

Annahmen :

• Der Linux-Kernel hat Fehler, aber grsec reicht aus, um dies zu beheben. Kann kein Angriffsvektor sein, wenn grsec nicht deaktiviert ist
• Grsec und SElinux haben keine Fehler und sind nicht falsch konfiguriert.
• Ein Benutzer root im Container ist root außerhalb des Containers (vielleicht wird dies eines Tages nicht mehr wahr sein ...)
• Docker ist ein realer Docker. Keine bekannten Fehler, wurde aber in der Vergangenheit von Fehlern betroffen und es könnte wieder vorkommen.
• Ein Protokollsystem für zukünftige Untersuchungen ist bereits ordnungsgemäß eingerichtet.

Ziel :

• Schützen Sie die Flaggen. Wahrscheinlich nicht möglich, da wir davon ausgehen, dass Docker Fehler aufweist.
• Angriffsfläche reduzieren.
• Machen Sie dem Angreifer das Leben schwer.
• Stellen Sie einen Alarm ein, der ausgelöst wird, wenn der Angreifer versucht, die Flags zu erhalten. Am liebsten lange bevor er es geschafft hat sie zu bekommen.

Fragen :

• Wie realistisch sind meine Annahmen?
• Wie würden Sie diese Ziele erreichen?
• Wie sind meine folgenden Vorschläge?
• Irgendwelche allgemeinen Sicherheitshinweise für Docker?

Meine Vorschläge :

• Konfigurieren Sie SElinux so, dass kein Benutzer auf A schreiben kann und kein Benutzer Dateien auf V ausführen kann.

• Verwenden Sie ein extrem minimales Docker-Image ohne Benutzerland. Etwas wie:

  FROM scratch
  COPY app /
  ENTRYPOINT ["/app"]
  

• Deeskalieren Sie die Berechtigungen, bevor Sie die App ausführen. (Ich bin mir nicht sicher, wie ich das richtig machen soll ...)

• Ein gefälschtes Busybox-User-Land? Etwas, das einen Alarm auslösen würde, wenn wir versuchen, /bin/sh, /bin/ls oder so ähnlich.