Container & Volumes FAQ

Die folgenden Fragen und Antworten erklären Aufbau und Sicherheitsprinzipien der Container-Architektur.

Nein. Der dev-Container ist die Vertrauenszone der Entwicklungsumgebung. Er hat in dieser Guideline Schreibzugriff auf den Workspace.

Ein kompromittierter Prozess könnte Projektdateien verändern. Der Zugriff bleibt jedoch auf das Projektverzeichnis beschränkt.

Nein. Container sehen nur explizit gemountete Pfade innerhalb der Docker Compose.

~/Work/kunde-1/projekt-1

Andere Teile des Host-Systems sind nicht sichtbar. Dies wird zusätzlich durch Docker Desktop unterstützt, das auf macOS nur explizit freigegebene Pfade mounten kann.

Ja, aber nur bedingt. Wenn das Projektverzeichnis vom Host-System in einen Container schreibbar gemountet wird, greifen Prozesse im Container direkt auf Dateien im Host-Dateisystem zu. Änderungen im Container werden daher auf dem Host-System sichtbar.

Eine schadhafte Dependency kann so Dateien im Workspace erzeugen oder verändern, die anschließend auf dem Host liegen.

Wichtig: Die Datei kann nicht direkt aus dem Container auf dem Host ausgeführt, jedoch später durch Benutzeraktionen getriggert werden.

Risiken

• Git Hooks (.git/hooks)
• Build-/Projekt-Skripte (package.json, IDE Tasks)

Maßnahme

• Git Hooks deaktivieren / kontrollieren (core.hooksPath)
• automatische Tasks vermeiden
• Änderungen nach Dependency-Updates prüfen

Dieses Risiko lässt sich bei einem lokal gemounteten Workspace nur begrenzt reduzieren. Eine stärkere Isolation wäre etwa durch Development Container auf einem Remote-Host per SSH möglich.

name ist nur ein Anzeigename für den dev-Container in der IDE.

workspaceFolder definiert den Projektpfad im Container, den VS Code öffnet.

workspaceFolder sollte mit working_dir und den Volume-Mount-Pfaden in compose.yml übereinstimmen.

name muss nicht mit dem Compose-Projektnamen übereinstimmen — workspaceFolder hingegen sollte konsistent sein.

Der dev-Container nutzt SSH Agent Forwarding.

Das ermöglicht:

• Git Zugriff über SSH
• Nutzung vorhandener SSH Keys

Nein.

Der Container erhält nur Zugriff auf den SSH Agent, nicht auf die Schlüssel selbst. Der private Schlüssel bleibt ausschließlich auf dem Host.

Nein.

Docker Compose erstellt automatisch projektspezifische Volume-Namen.

Beispiel:

security-oriented-dev-container-project_node_modules
other-project_node_modules

Jedes Projekt bekommt seine eigenen Volumes.

Einige Container überdecken bestimmte Projektverzeichnisse mit tmpfs.

Beispiel:

tmpfs:
  - /workspaces/security-oriented-dev-container-project/.git

tmpfs mountet ein temporäres RAM-Dateisystem über diesen Pfad.

Das bedeutet:

• das originale Verzeichnis aus dem Bind Mount ist im Container nicht sichtbar
• stattdessen existiert ein leeres temporäres Verzeichnis

Diese Technik wird genutzt, um sensible Daten auszublenden.

Einige tmpfs Mounts verwenden zusätzliche Mount-Optionen, zum Beispiel:

tmpfs:
  - /tmp:rw,nosuid,nodev

Diese Optionen schränken ein, wie das temporäre Dateisystem im Container genutzt werden darf.

Ein Container kann mit einem read-only Root Filesystem gestartet werden.

read_only: true

Das bedeutet:

• das Container-Dateisystem kann nicht verändert werden
• Programme können keine Dateien im Root-Filesystem schreiben
• nur explizit gemountete Volumes bleiben beschreibbar

Dadurch wird verhindert, dass ein Prozess im Container:

• Systemdateien verändert
• zusätzliche Software installiert
• persistente Änderungen im Container vornimmt

Docker Container starten normalerweise mit einer Reihe von Linux Capabilities.

Mit

cap_drop: ALL

werden alle zusätzlichen Capabilities entfernt. Der Container erhält nur noch die minimal notwendigen Rechte. Das reduziert die Angriffsfläche innerhalb des Containers.

Die Docker Option

no-new-privileges:true

verhindert, dass Prozesse im Container zusätzliche Privilegien erhalten.