Zielgruppe und Einordnung

Für viele Projekte genügt ein klassischer Dev Container. Diese Guideline geht bewusst einen Schritt weiter.

Der folgende Abschnitt soll dabei helfen einzuordnen, für wen dieser Ansatz gedacht ist und warum er so aufgebaut ist, wie er ist.

Ausgangspunkt

Ein erster Schritt weg von Host-Installationen ist oft, die Entwicklungsumgebung in einen Container zu verlagern. Das hält den Host sauber, verbessert Reproduzierbarkeit und verhindert Toolchain-Konflikte.

Ein klassischer Dev Container bleibt jedoch ein großer Vertrauenskontext: SSH-Keys, Git-Credentials, Tokens, Projektcode, Dependencies und Laufzeit-Secrets liegen gemeinsam vor.

Diese Guideline geht einen Schritt weiter und verteilt die Entwicklungsumgebung auf mehrere Container mit unterschiedlichen Vertrauensstufen.

Der Ansatz dieser Guideline

Statt eines Containers mit umfassenden Rechten, nutzt dieser Ansatz spezialisierte Container mit minimal notwendigem Kontext. Die Trennung folgt nicht technischen Schichten wie Frontend oder Backend, sondern der Frage:

Wer braucht wofür welche Rechte, Secrets und Netzzugänge?

So bleibt der Schaden eines kompromittierten Containers auf seinen Kontext begrenzt. Ein bösartiges NPM-Package im deps-Container findet z.B. weder Secrets noch SSH-Keys - und kann auch den Projektcode nicht verändern.

Die Rolle der AI-Kontexte

Das Setup trennt bewusst zwei AI-Kontexte: Der ai-Container mit Lesezugriff für Analyse und Planung, der ai-agent-Container mit Schreibzugriff für Änderungen am Projekt.

So kann AI-Tooling genutzt werden, ohne ihm denselben Vertrauenskontext wie dem Entwickler zu geben.

Wann sich dieser Ansatz lohnt

Der Aufwand dieser Architektur lohnt sich insbesondere, wenn:

mit fremdem Code gearbeitet wird
viele transitive Dependencies genutzt werden
AI-Tooling bewusst eingeschränkt werden soll
mehrere Projekte parallel betreut werden
sensible Secrets oder Credentials im Einsatz sind