Blog · Platform Engineering
GitLab Workspaces auf AKS: Sichere Sandboxes für KI-gestützte Entwicklung.
KI-Coding-Agents entfalten ihren Wert erst mit echtem Terminal-Zugriff. Jedoch birgt dieser Zugriff auch einige Risiken.
In diesem Beitrag zeigen wir, wie Gitlab Workspaces auf AKS dieses Dilemma lösen und Entwicklern die Möglichkeit geben, in einer isolierten, jederzeit wegwerfbaren Umgebung zu arbeiten.
TL;DR
- KI-Coding-Agents brauchen Terminal-Zugriff, und lokal ist das ein Sicherheitsrisiko für Laptop und Zugangsdaten.
- GitLab Workspaces starten pro Branch eine netzwerk-isolierte Dev-Umgebung im eigenen AKS-Cluster, die alle benötigten Tools (VS Code, Terminal, Git, Claude Code etc.) vorinstalliert hat.
- Umgebungen sind temporär: automatischer Stopp bei Inaktivität, Node-Pool skaliert auf null, Kosten pro Node-Stunde statt pro Workspace.
- Mit Terraform + Helm + AKS steht das komplette Setup in Tagen, nicht Wochen.
Volle Rechte für den Agenten: Auf wessen Rechner?
KI-Coding-Agents wie Claude Code oder Copilot Workspace werden erst dann richtig produktiv, wenn sie mehr dürfen als Text vervollständigen: Dependencies installieren, Tests ausführen, Migrationen laufen lassen, Dev-Server starten. Kurz gesagt, wenn sie ein echtes Terminal bekommen.
Genau da beginnt das Problem. Ein Agent mit Shell-Zugriff auf dem Entwickler-Laptop kann im Fehlerfall dieselben Schäden anrichten wie jeder andere Prozess mit diesen Rechten: Dateien löschen, Zugangsdaten aus ~/.ssh, ~/.aws oder dem Keychain auslesen, ungewollt Pakete mit Postinstall-Skripten ausführen. Schränkt man Agents deshalb eng ein, verliert man den Großteil ihres Nutzens. Gibt man ihnen freie Hand, muss man darauf vertrauen, dass nichts schiefgeht. Beides ist unbefriedigend.
Der Ausweg: Der Agent bekommt volle Rechte, aber nicht auf dem Laptop, sondern in einer isolierten, jederzeit wegwerfbaren Umgebung im eigenen Kubernetes-Cluster. Genau das leisten GitLab Workspaces auf Azure Kubernetes Service (AKS). In diesem Beitrag zeigen wir, welche drei Probleme dieses Setup löst und warum der Aufbau mit Terraform und Helm eine Sache von Tagen ist, nicht von Wochen.
Sandboxing: Gefahrlos experimentieren
Jede Workspace läuft als eigener Pod im Cluster, nicht auf dem Entwicklerrechner. Was der Agent (oder der Mensch) dort anrichtet, bleibt dort. Der entscheidende Teil ist aber nicht die Pod-Grenze allein, sondern das Netzwerk-Design dahinter. Ein Pod mit uneingeschränktem Cluster-Netzzugriff wäre keine Sandbox, sondern ein Brückenkopf.
Deshalb bekommt jede Workspace eine eigene NetworkPolicy mit klaren Regeln, was sie erreichen darf und was nicht:
Egress-Lockdown
Ausgehend sind nur DNS sowie Internet auf den Ports 443 und 80 erlaubt, genug für Paket-Registries und Git, nicht mehr.
Metadata-Dienst gesperrt
Jeder Cloud-Server hat eine interne „Auskunftsstelle", bei der sich Programme Cloud-Zugangsschlüssel abholen können. Dieser Weg ist aus der Sandbox komplett gesperrt.
Keine Ausbreitung im Netzwerk
Jede Workspace hat ihre eigene NetworkPolicy. Workspaces sehen einander nicht, und auch keine anderen Anwendungen im Cluster.
Interne Systeme: Sie entscheiden
Zugriff auf interne Netze ist standardmäßig zu, lässt sich aber gezielt freischalten, etwa für eine Test-Datenbank. Da alles in der eigenen Netzwerkumgebung läuft, haben Sie volle Flexibilität.
Der erklärungsbedürftigste Punkt ist der gesperrte Metadata-Dienst. Jeder Server in der Cloud hat eine eingebaute „Auskunftsstelle" (bei Azure: Instance Metadata Service, kurz IMDS), die unter einer festen internen Adresse erreichbar ist. Dort kann sich jedes Programm, das auf dem Server läuft, Informationen und vor allem Zugangsschlüssel für die Cloud-Umgebung abholen, gedacht ist das eigentlich nur für den Server selbst. Ohne Sperre könnte aber auch Code in einer Workspace dort anklopfen und Schlüssel bekommen, die deutlich mehr dürfen als die Sandbox, ungefähr so, als könnte jeder Hotelgast an der Rezeption den Generalschlüssel abholen. Deshalb wird genau dieser Weg per NetworkPolicy geschlossen; das ist auch die offizielle Sicherheits-Empfehlung von Microsoft für AKS-Cluster.
Für die internen Netzbereiche gilt dagegen: standardmäßig zu, aber frei konfigurierbar. Weil die Workspaces in der eigenen Netzwerkumgebung laufen, entscheiden Sie selbst, welche internen Systeme eine Dev-Umgebung erreichen darf: die Test-Datenbank ja, das Produktivsystem nein. Genau diese Flexibilität bietet kein externer Cloud-IDE-Dienst.
Das Ergebnis: Man kann den Agent Worst-Case-Kommandos ausprobieren lassen, ein destruktives Skript, eine unbekannte Dependency, ein rm -rf an der falschen Stelle, ohne um Laptop, SSH-Keys oder Cloud-Zugangsdaten zu bangen. Im schlimmsten Fall löscht man die Workspace und klickt eine neue.
Sicherheit und Segmentierung bei voller Agenten Power
Pro Feature-Branch eine eigene Umgebung
Das zweite Problem ist älter als jeder KI-Agent: das lokale Umgebungs-Setup. Neue Teammitglieder verlieren ihren ersten Tag (oder ihre erste Woche) an Toolchain-Installation, und wer parallel an drei Branches mit unterschiedlichen Dependency-Ständen arbeiten will, jongliert mit Node-Versionen, Datenbank-Containern und halb migrierten Schemas.
Mit Workspaces wird daraus ein Klick: „New Workspace" auf einem Branch oder Merge Request, und nach ein bis zwei Minuten steht eine vollständige Browser-Dev-Umgebung mit Editor und Terminal bereit, ausgecheckt auf exakt diesem Branch.
Technisch steckt dahinter ein goldenes Image: ein einmal gebautes Basis-Image mit dem Standard-Tooling des Teams. Projektspezifisches kommt zur Laufzeit über ein Devfile dazu, einen offenen CNCF-Standard, der die Umgebung deklarativ neben dem Code im Repository beschreibt:
schemaVersion: 2.2.0
components:
- name: tooling
container:
image: registry.example.com/dev/golden-base:latest
memoryRequest: 2Gi
memoryLimit: 8Gi
commands:
- id: setup
exec:
component: tooling
commandLine: npm ci && npm run db:migrateSo pflegt man ein Image für alle Projekte statt eines pro Projekt, und trotzdem bekommt jedes Repository exakt die Umgebung, die es braucht. Das Problem „Works on my machine" stellt sich gar nicht erst: Die Umgebung, in der der Agent gearbeitet hat, ist dieselbe, in der der Reviewer den Branch öffnet.
Kosten: Temporär statt Dauerbetrieb
Klassische Dev-VMs haben eine unangenehme Eigenschaft: Sie kosten auch dann Geld, wenn niemand daran arbeitet, nachts, am Wochenende, im Urlaub. Workspaces sind dagegen konsequent temporär: Nach einer definierten Inaktivitätszeit stoppt die Umgebung automatisch (die Rechenleistung geht auf null, das Datenvolumen bleibt erhalten), nach längerer Inaktivität wird sie ganz gelöscht.
Der eigentliche Hebel liegt im Cluster: Der Kubernetes-Autoscaler skaliert den Node-Pool für Workspaces bis auf null Nodes herunter, wenn nichts läuft. Kosten fallen pro Node-Stunde an, nicht pro Workspace, und mehrere Workspaces teilen sich einen Node, sodass die fünfte parallele Umgebung kaum mehr kostet als die erste.
0
Nodes bei Inaktivität
1–2 Min.
bis zur fertigen Umgebung
Node-Std.
Kosteneinheit, nicht pro Workspace
Und weil das Ganze nativ in GitLab integriert ist, gibt es kein separates Tool, keinen separaten Login, keine zusätzliche Lizenzverwaltung für ein Cloud-IDE-Produkt: Die Workspace ist ein Button im Merge Request.
Was sind GitLab Workspaces eigentlich?
GitLab Workspaces sind das native Remote-Development-Feature von GitLab (Premium/Ultimate, GA seit GitLab 16.7, auf gitlab.com, Self-Managed und Dedicated). Ein Klick auf einem Branch oder Merge Request erzeugt einen Pod im eigenen Kubernetes-Cluster, der Code und die Laufzeitumgebung verlassen also nie die eigene Infrastruktur. Das unterscheidet Workspaces auch von der GitLab Web IDE: Die ist nur ein Browser-Editor ohne Terminal und ohne Runtime.
Das für die Security-Bewertung wichtigste Architektur-Detail: Die Steuerung läuft über einen In-Cluster-Agenten, der sich ausschließlich ausgehend per WebSocket mit GitLab verbindet. GitLab wählt sich nie von außen ins Cluster ein. Es gibt also keinen eingehenden Management-Zugriff, den man absichern oder in der Firewall freischalten müsste.
Die Umgebungen selbst werden über Devfiles beschrieben (CNCF-Standard, Schema-Version 2.2.0), ein offenes Format statt eines proprietären. devcontainer.json wird derzeit nicht unterstützt. Der Lebenszyklus ist bewusst simpel: erstellen → laufend → nach Inaktivität gestoppt (Volume bleibt) → neu starten oder löschen.
Das Setup: Tage statt Wochen
Die nötige Infrastruktur klingt nach viel: Kubernetes-Cluster mit Autoscaling und Standard-Storage-Klasse, Ingress-Controller, Wildcard-DNS und Wildcard-TLS, Registry, der GitLab-Agent und ein Workspaces-Proxy. Mit dem richtigen Werkzeug-Stack ist genau das aber kein wochenlanges Infrastrukturprojekt:
Terraform
Die gesamte Infrastruktur, Netzwerk, Registry, DNS, Identitäten, als Code. Reviews laufen über den Merge Request, und ein zweites Cluster ist in Minuten neu aufgesetzt.
Azure AKS
Managed Kubernetes mit Cluster-Autoscaler und Workload Identity: passwortlose Cloud-Identität statt gespeicherter Secrets, also ein Angriffsvektor weniger.
Helm Charts
Ingress-Controller, Zertifikatsverwaltung, GitLab-Agent und Workspaces-Proxy kommen als fertige Charts. Man verdrahtet Standard-Bausteine, statt alles selbst zu bauen.
Kubernetes
Die Laufzeit-Voraussetzung des Features: Cluster mit Autoscaling und Standard-Storage-Klasse, dazu Wildcard-DNS und Wildcard-TLS für die Workspace-URLs.
Die Kernaussage: IaC (Terraform) + Paketmanager (Helm) + managed Kubernetes (AKS) verwandeln den Aufbau in das Verdrahten erprobter Standard-Bausteine. Und weil alles Code ist, lässt sich das Setup 1:1 in eine zweite Umgebung übertragen, Staging heute, ein zweites Team-Cluster nächste Woche.
Das Ergebnis
Der Endzustand fühlt sich unspektakulär an, und genau das ist der Punkt: Entwickler oder KI-Agent klicken „New Workspace" auf einem Branch, und nach etwa ein bis zwei Minuten steht eine vollständig isolierte, browserbasierte VS-Code-Umgebung mit Terminal und vorinstalliertem Standard-Tooling bereit. Niemand muss sich durch ein VPN kämpfen, eine Setup-Anleitung im Wiki nachschlagen oder um den eigenen Rechner bangen.
Die Kosten bleiben planbar über eine harte Obergrenze für gleichzeitig laufende Workspaces plus automatisches Stoppen nach Inaktivität. Nachts und am Wochenende skaliert der Node-Pool auf null.
Und das Muster ist nicht branchenspezifisch: Es passt für jedes Team, das KI-Coding-Agents, externe Contractor oder einfach viele parallele Experimente sicher einbinden will, überall dort, wo „gib der Person (oder dem Agenten) mal eben Zugriff" heute noch ein mulmiges Gefühl auslöst.
- ✓ Isolierte Browser-IDE mit Terminal in 1–2 Minuten pro Branch oder Merge Request
- ✓ Agent-sicher: Egress-Lockdown, gesperrter Metadata-Dienst, NetworkPolicy pro Workspace, interne Zugriffe frei konfigurierbar
- ✓ Planbare Kosten: harte Obergrenze für parallele Workspaces, Scale-to-Zero bei Inaktivität
- ✓ Vollständig im Git-Workflow, ohne separates Tool und ohne separaten Login
Sichere Sandboxes für Ihr Team?
Wir setzen GitLab Workspaces auf AKS, oder einem Kubernetes Ihrer Wahl, in wenigen Tagen produktionsreif auf: Terraform, Helm, Netzwerk-Isolation und Kosten-Guardrails inklusive.