Sichere Entwicklung und AI-Isolation mit Dev Containern

Devcontainers Cover

Moderne Softwareentwicklung bedeutet oft, Code auszuführen, den man nicht selbst geschrieben hat. Jedes Mal, wenn npm run dev ausgeführt wird, läuft Code von Dritten. Dies stellt ein erhebliches Sicherheitsrisiko dar, wenn dieser Code mit erhöhten Benutzerrechten auf dem Host-System ausgeführt wird. Die konkreten Gefahren sind unter anderem:

Backdoors: Schadcode, der eine versteckte Hintertür im System einrichtet, über die Angreifer jederzeit unbemerkt Zugriff erhalten können.
Datenverlust: Dateien auf dem Host-System können gelöscht, verschlüsselt oder manipuliert werden.
Datenexfiltration: Sensible Daten wie SSH-Schlüssel, Zugangsdaten oder persönliche Dateien können unbemerkt an Angreifer gesendet werden.

AI-Agenten bringen neue Risiken. Obwohl leistungsfähig, sollten diese Agenten keinen uneingeschränkten Zugriff auf Ihre persönlichen Dateien, SSH-Schlüssel oder andere Dinge auf dem Host-System haben. Neben den oben genannten Risiken kommen bei AI-Agenten noch weitere hinzu:

Prompt Injection: Versteckte Anweisungen auf Websites oder in Code-Repositories können AI-Agenten dazu bringen, ungewollte Aktionen auszuführen, etwa Daten nach aussen zu senden oder schädlichen Code einzubauen.
Unerwartete Fehler: AI-Agenten können schlicht fehlerhafte Aktionen ausführen, z.B. Dateien überschreiben oder löschen.

Die Strategie: Isolation (Containment)

Bei Tanner Lab nutzen wir Dev Container, um beide Probleme zu lösen. Indem wir die Entwicklung in Docker-Container verlagern, erreichen wir eine standardisierte, reproduzierbare und isolierte Umgebung.

Wir haben eine Strategie mit zwei Containern für unsere Repositories eingeführt:

Menschliche Entwicklung (dev--{repository-name}): Zum isolierten Ausführen und Entwickeln von Code.
AI-Sandbox (ai--{repository-name}): Für die Zusammenarbeit mit AI-Agenten.

Architekturdiagramm

1. Sichere Menschliche Entwicklung

Der Entwicklungs-Container ist für den menschlichen Entwickler konzipiert. Er benötigt Zugriff auf Umgebungsvariablen (Secrets) und muss Ports freigeben, um die Anwendung anzuzeigen. Indem er jedoch in einem Container läuft, stellen wir sicher, dass das Ausführen von unbekanntem Code (z.B. node_modules) das Host-System nicht gefährdet.

dev/devcontainer.json:

{
  "name": "dev--my-app",
  "runArgs": [
    "--env-file", "${env:HOME}/dot-env-files/my-app.env",
    "-p", "3000:3000"
  ],
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind"
}

2. Isolation von AI-Agenten

AI-Agenten müssen oft den Code lesen, um den Kontext zu verstehen, benötigen aber keinen Zugriff auf Laufzeit-Credentials. Wir führen sie in einem separaten Container aus.

Dieser Container hat keine projektspezifische Umgebungsvariablen. Er schafft eine sichere Sandbox, in der ein Agent am Code arbeiten kann, ohne das Risiko, versehentlich Zugangsdaten zu leaken oder auf andere Teile des Systems zuzugreifen.

ai/devcontainer.json:

{
  "name": "ai--my-app",
  // Keine env-file, kein Port-Forwarding
  "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind",
  "customizations": {
    "vscode": {
      "extensions": ["anthropic.claude-code", "openai.chatgpt", "Google.geminicodeassist"]
    }
  }
}

Referenzimplementierung

Wir haben eine Referenzimplementierung mit Vike, React und Tailwind veröffentlicht, um die Idee besser nachvollziehen zu können.

Sie enthält die komplette Ordnerstruktur und Konfiguration, welche in andere Projekte kopiert werden kann.

.devcontainer/
├── ai/
│   ├── Dockerfile
│   └── devcontainer.json
└── dev/
    ├── Dockerfile
    └── devcontainer.json

Zum Repository auf GitHub: tannerlab/working-with-devcontainers