Bevorzugte Architektur

Die in dieser Guideline beschriebene Entwicklungsumgebung baut auf dem Development Container + Service Container Architekturansatz auf und besteht dabei aus mehreren spezialisierten Containern.

---

Das Host-System enthält bewusst keine projektspezifische Toolchain:

• keine Node-Installation
• keine Projektdependencies
• keine Build-Tools

Unterschiedliche Aufgaben wie Installation von Abhängigkeiten, Entwicklung oder App-Runtime werden gezielt auf getrennte Container verteilt.

Dadurch gilt:

• kein Container hat automatisch Zugriff auf alle Ressourcen
• Angriffsflächen bleiben begrenzt

Secrets werden ausschließlich dort bereitgestellt, wo sie tatsächlich benötigt werden.

Beispiele:

• Registry-Tokens
• Git-/SSH-Konfiguration
• Runtime-Konfiguration

Ziel ist eine kontextspezifische Secret-Verteilung statt globaler Verfügbarkeit.

Die Container werden mit einfachen, aber effektiven Hardening-Maßnahmen betrieben. Diese Maßnahmen reduzieren die Auswirkungen kompromittierter Prozesse innerhalb eines Containers.

---

Der bevorzugte Architekturansatz reduziert Risiken, eliminiert sie jedoch nicht vollständig.

Mehrere Container greifen auf das Projektverzeichnis zu (Bind Mount).

Das bedeutet:

• Container können Dateien auf dem Host-System verändern
• manipulierte Dateien können andere Container beeinflussen
• Angriffe über Build-/Runtime-Ketten bleiben möglich

Container bieten eine starke, aber keine perfekte Isolation.

Restrisiken bestehen u.a. durch:

• Kernel-Schwachstellen
• Container-Escape-Exploits
• Fehlkonfigurationen (Capabilities, Mounts, Netzwerk)

Diese Risiken sind Docker-basierten Entwicklungsumgebungen grundsätzlich inhärent.