Zielgruppe und Einordnung

Diese Guideline beschreibt einen Ansatz für eine sicherheitsorientierte lokale Entwicklungsumgebung, der bewusst aufwendiger ist als ein klassisches Dev Container Setup.

Dieser 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.

Die Rolle der AI-Kontexte

Das Setup trennt bewusst ai- und ai-agent-Container.

AI-Tools haben sich von Autocomplete-Helfern zu Agenten entwickelt, die Code lesen, ausführen und verändern können. Viele Setups geben ihnen denselben Kontext wie dem Entwickler – inklusive Zugriff auf Keys und Tokens.

Diese Guideline behandelt AI-Tools bewusst als nur eingeschränkt vertrauenswürdig.

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