# Docker Sandboxes: Securing AI Agents

**Podcast:** INNOQ Podcast
**Published:** 2026-10-05

## Transcript

Hallo und herzlich willkommen zum InnoCube Podcast.
Mein Name ist Anja Kammer und heute spreche ich mit Stefan Bodewig und Michael Krämer über Docker Sandboxes.
Hallo.
Hallo.
Hallo.
Schön, dass ihr beide da seid.
Gleich zwei Experten, mit denen ich sprechen kann.
Ihr habt vielleicht auch unterschiedliche Erfahrungen mit diesem neuen Tooling gemacht.
Das Erste, was mich interessiert, ist, wozu benutzt man Docker Sandboxes überhaupt?
Also warum haben wir uns dann eigentlich getroffen?
Was ist eine Sandbox überhaupt?
Naja, es geht darum, dass ich unter Umständen Software ausführen möchte, der ich nicht hundertprozentig vertraue und der irgendwie einen Rahmen verpassen möchte, aus dem sie nicht ausbrechen kann, wo sie irgendwie keinen großen Schaden auf meinem System einrichten kann.
Kontexte kann es ganz viele geben, aber es geht tatsächlich darum, dass ich vielleicht meine Geheimnisse für mich behalte und ich nicht diese Software verrate, die ich ausführen möchte, ausführen muss vielleicht aus irgendwelchen Gründen.
eher nicht beliebigen Netzwerkzugriff ermitteln möchte, solche Dinge.
Also ich brauche irgendwie ein Gefängnis, eine Quarantänestation für ein Stück Software, dem ich nicht vertraue.
Und welche Schäden können dann angerichtet werden?
Also man erstellt ja so etwas wie eine Quarantäne aus einem bestimmten Grund, damit halt Schäden nicht entstehen können.
Welche Schäden sind da?
Also was ist das für ein Bedrohungsszenario?
Naja, also man muss sich das ja so vorstellen, dass jetzt zum Beispiel ein KI-Agent, wenn wir den jetzt lokal starten, dann hat er erstmal alle Rechte, die der Benutzer auch hat.
Das heißt, er könnte nicht nur die Dateien im Projektverzeichnis lesen, sondern im Prinzip alles, was auf der Festplatte ist, also zumindest was für den User im Zugriff ist.
Er könnte...
auch weitere Dinge auf dem Computer installieren, wenn ich zum Beispiel einen dem, ja, oder wenn der Agent versucht, den Browser zu benutzen, was der Agent zumindest kann, dann hat er automatisch alle Cookies, die ich im Browser habe.
Also wenn ich irgendwo eingeloggt bin, dann sieht das für den anderen Service ja so aus, als sei das ich.
Und da ...
Oder genauso ist es auch mit Schlüsseln.
Wenn ich jetzt zum Beispiel meinen SSH-Key in meiner Maschine entsperrt habe über so ein Tool, das nur einmal die Passphrase eingeben muss, dann ist der SSH-Key einfach verfügbar.
Und dann könnte der Agent auch damit irgendwas tun.
Und manchmal will ich das ja vielleicht auch, aber dann möchte ich das vielleicht irgendwie kontrollieren können und nicht einfach darauf vertrauen, dass das schon passen wird.
Zum Beispiel mit einem Extra-Key nur für den Agenten zum Beispiel.
Jetzt im Falle von den Keys, genau.
Oder halt mit einem eigenen Browser oder browserähnlichen Tool oder mit irgendeiner Form von Kapselung.
Das ist eigentlich das, was man mit der Sandbox dann erreichen möchte.
Ich persönlich habe noch einen anderen Anwendungsfall.
Also ich persönlich möchte mich zum Beispiel vor Würmern schützen, gerade im JavaScript Packages.
Universum gibt es ja jetzt ganz schön viele Würmer, die schon lange Zeit wüten oder wieder wüten.
Und ich würde mich halt eher gerne davor schützen, dass Packages, die ich runterlade, nicht dann meinen ganzen PC sozusagen dann befallen und Dinge löschen, was ich da schon alles für Horror-Stories gehört habe.
Kann ich Docker-Sandboxes oder generell Sandboxes halt auch dafür benutzen?
Also grundsätzlich schon.
Also ganz sicher.
Das sind ja durchaus...
Bedrohungsszenarien, wie das, was Michael auch gerade beschrieben hat, dass ich eben meine Secrets, die in meinem lokalen Verzeichnis liegen könnte, der Wurm benutzen, um bei GitHub in meinem Namen commits vorzunehmen, um irgendwelche Secrets auszulesen und die irgendwo hin zu pushen.
Neue Releases von neuen Open-Source-Projekten zu machen, die eine Hintertür enthalten, um sich als Wurm weiter zu verbieten.
All diese Dinge würde ich...
in einer Sandbox zumindest erheblich erschweren.
Ich würde im Zweifel auch nicht meine Credentials in der Sandbox haben, mit denen man neue Releases bauen könnte, mit denen man irgendwie GIT-Commits machen könnte.
Du willst ja nur in deinem Fall neue Pakete installieren, gucken, ob das Update funktioniert.
Dafür musst du ja keine Änderungen vornehmen können.
Also du würdest eigentlich eine Read-Only-Umgebung, reicht dir an dieser Stelle.
Die muss ja nicht selber irgendwo was ändern können.
Wenn du siehst, dass alles funktioniert, dann kannst du anschließend die Änderung eben außerhalb der Sandbox vornehmen.
Wenn du siehst, das ist soweit in Ordnung, das Update hat keinen Schaden angerichtet an der Stelle.
Wobei man da dazu sagen muss, also eigentlich würde, also ich sehe das zumindest so, dass die Sandbox an der Stelle eigentlich den Blast Radius einfach verkleinert.
Also was jetzt zumindest nicht standardmäßig dabei ist.
Wenn du ein Paket runterlädst, wo ein Wurm drin ist, dann würde er das nicht erkennen.
Also so wie das in manchen Unternehmen ist, so eine Art Content-Firewall oder irgendwelche Fingerprints überprüft.
Es gibt ja erstmal einfach Tools, mit denen du eingehenden Netzwerkverkehr oder ausgehenden Netzwerkverkehr oder auch den Zugriff auf deine Dateien halt irgendwie schützen kannst.
Aber es ist jetzt nicht so, dass da ein Virenscanner oder irgendwas schon dabei wäre.
Absolut.
Um auf das Erste, was ich gesagt habe, nochmal einzugehen, Software, der ich nicht vertraue, das macht die Software, die ich ausführe, nicht vertrauenswürdiger, die ich in der Sandbox ausführe, sondern ich nehme ihr Möglichkeit, Schaden anzurichten.
Wahrscheinlich auch nicht vollständig, aber ich schränke zumindest stark ein, welchen Schaden sie anrichten kann.
Und Wir reden über, also wir wollen heute ja über Docker-Sandboxes sprechen und wenn ich jetzt Docker höre, dann denke ich an Container.
Ist diese Sandbox ein Container einfach nur, der besondere Mechanismen noch hat oder wie sieht das aus?
Nein, also das hat jetzt mit Docker oder Docker-Containern eigentlich nur den Namen gemeinsam.
Also die Technologie basiert auf einer Micro-VM.
Und es hat schon ein bisschen Parallelen mit der Form des Dateisystems, aus dem die Images oder mit dem die VM erstellt wird.
Da gibt es, glaube ich, ein paar Parallelen.
Aber ansonsten ist es eine Micro-VM.
Es gibt keinen geteilten Kernel, so wie es bei Docker wäre.
Bei Docker habe ich ja jetzt vereinfacht gesagt nur eine Prozessisolation.
Und das hier ist wirklich eine eigene, sehr schlank gehaltene VM und in der kann ich dann entsprechende Software ausführen, wie zum Beispiel so einen Agent.
Da hat, glaube ich, das Marketing von Docker Incorporated hervorragend funktioniert, dass wir in unserem Kopf Docker synonym mit Linux-Containern sehen und als Containerlösung sehen.
Und das ist mir zu Anfang auch ganz genau so gegangen, dass ich...
zwar irgendwo wusste, das ist eine virtuelle Maschine und kein Docker-Container, aber trotzdem mir so Container-Fragen gestellt habe.
Wie mache ich denn da ein Betriebssystem-Update von der Basis, die unten drunter liegt oder solche Dinge?
Wenn das alles immutable ist, ist es eben nicht.
Weil es eine virtuelle Maschine ist, kann ich eben auch Änderungen durchführen und persistieren innerhalb der Maschine.
Michael, du hast gerade gesagt, ein Container ist ja nicht so sicher wie eine virtuelle Maschine.
Kannst du das nochmal ausführen?
Weshalb nicht?
Also ein Container hat eine geringere Isolation als jetzt eine VM, also die Virtual Machine.
Jetzt erzähle ich hoffentlich keinen Quatsch.
Also die Virtual Machine, die Virtualisierung einer virtuellen Maschine ist ja letzten Endes ein Hardware-Feature von...
von den CPUs, wo man die Möglichkeit hat zu virtualisieren und dann quasi auch eine virtuelle CPU, einen virtuellen Computer bereitzustellen.
Und darauf läuft dann ein komplettes Betriebssystem.
Und bei Docker ist das anders.
Wenn ich einen Docker-Container starte, dann teilen sich alle Docker-Container, die auf einem Docker-Host laufen, den gemeinsamen Kernel des Host-Betriebssystems.
Das ist eben hier ein anderer Fall.
Dadurch ist die Isolation einfach nochmal einen Tick höher.
Ich glaube aber in der Praxis, das ist jetzt dann zwar nochmal ein anderes Thema, vielleicht kommen wir da eher später nochmal drauf, ist aber so, wenn ich jetzt in einem Container Software entwickle, dann komme ich halt an dieses Phänomen Docker in Docker.
Also, dass ich dann halt vielleicht für mein Bild von der Software oder für irgendwas, was ich wäre, was ich zu Zwecken meiner Softwareentwicklung ausführen möchte, brauche ich selber wieder Docker.
Und das ist relativ komplex, das dann durchzuführen, sodass es wirklich eine gute Isolation hat.
Ich würde jetzt mal behaupten, jemand, der einen strengeren Security-Fokus hat, wie der Sprichbinder vielleicht, aber ich glaube, normalerweise würde die Isolation von einem Container vielleicht sogar ausreichen, aber der Meiner Meinung nach größter Angriffsvektor ist in einem Container dann, wenn ich halt in dem Container nochmal Docker brauche, weil ich dann einfach relativ viel aufmachen muss, damit man aus dem Container wieder auf den Docker-Host in irgendeiner Form draufkommt.
Und das brauche ich halt hier nicht.
Und praktischerweise ist es bei dem SBX, bei Docker-Sandbox ist sogar ein Docker-Host.
Also quasi...
In der MicroVM ist ein eigenes Docker installiert, aber komplett getrennt von der Hauptmaschine, auf der ich eigentlich arbeite.
Also ich glaube zumindest in der Praxis ist das eigentlich das Hauptfeature, wo ich glaube, dass es deutlich sicherer ist, als jetzt einen Container zu benutzen, um den Agenten laufen zu lassen.
Aber wir haben ja noch einen mehr Security-fokussierten Experten hier.
Tatsächlich, dass die beiden Systeme in einem Container, es sind ja nicht mal wirklich zwei Systeme, sondern dass der Container wie auch das Host-System im gleichen Linux-Körnel unterwegs sind, hat zusätzliche Angriffsvektoren, die ich nicht mehr habe, wenn ich da eine virtuelle Maschine zwischenziehe und wenn ich Bugs im Linux-Körnel habe, wenn ich Bugs in dem Teil des Codes habe, der das Namespacing macht und verhindert, dass ich aus dem Container heraus Dinge tue, die ich eigentlich nicht tun darf.
Dann sind das Angriffsvektoren, die wegfallen in dem Moment, wo ich die Extraschicht an Virtualisierung hinzufüge, wenn ich da eine virtuelle Maschine dazwischen schiebe.
Also tatsächlich eben stärkere Isolation an der Stelle.
Wobei ich, in Michels Fall, ich weiß, Michel nutzt im Gegensatz zu mir kein Linux als Host-Betriebssystem, sondern du bist auf dem Mac unterwegs.
Ich bin mir gar nicht so ganz sicher, ob die Isolation, ob Container, die du ausführst auf einem Mac, nicht zumindest auch von deinem Betriebssystem-Kernel isoliert wären.
Die würden halt in einem Linux-Kernel in der Docker-Engine laufen.
Vielleicht wäre da das Risiko sogar geringer, als das auf einem Linux-Host-Betriebssystem ist, wenn ich dort Container ausführe.
Bevor ich von Docker-Sandboxes gehört habe, habe ich mir selbst eine KVM-WM zusammengebastelt in meinem Linux-System.
Und als ich fertig war, habe ich mich dann gefragt, wie benutze ich das?
Und habe dann euch gefragt, wie benutze ich das?
Und ihr habt dann gesagt, warum benutzt?
du nicht Docker-Sandboxes.
Und da war ich ein bisschen traurig, dass ich mir so viel Mühe gegeben habe.
Aber ja, warum, also welche Features bringt mir Docker-Sandboxes, was ich sozusagen mit meiner eigenen VM nicht machen kann?
Ich vermute gar keine.
Also du könntest vermutlich sehr vieles von dem, was Docker-Sandboxes machen, auch selber hinbekommen, aber es wäre ziemlich viel Arbeit.
Also das, was du bekommst, ist in erster Linie mal Convenience.
Relativ viele Dinge, die da zusammenkommen, die in irgendeiner Art und Weise dafür sorgen, dass Netzwerkzugriff einfacher zu regulieren ist.
Du hast vor ein paar Monaten mit Joy einen Podcast gemacht.
Und Joy hat ja auch Artikel dazu geschrieben, wie sie KI-Agenten in mehrere Artikel in einer Sandbox sperrt.
Sie hat ja eigentlich genau das getan.
Sie hat ihre eigene Lima-VM genommen, was eine KVM-Lösung ist.
Sie hat ihren eigenen Proxy aufgesetzt.
Docker-Sandboxes kann wahrscheinlich noch ein bisschen mehr als das, was...
Joy in dem Artikel geschrieben hat.
Und es ist ziemlich viel Arbeit, das aufzusetzen, all diese Dinge zum Zusammenspielen zu bringen, dafür zu sorgen, dass das passt, dass ich, oh, jetzt merke ich, ich muss noch irgendwo hinzugreifen, dann muss ich meine Squid-Konfiguration ändern, muss Squid neu starten vielleicht, damit die Konfiguration gelesen wird.
All diese Dinge, die sind machbar, aber sie werden durch Docker-Sandboxes ein gutes Stück einfacher in der Umsetzung, sind bequemer.
Das ist so aus meinem...
für mich zumindest der Hauptgrund Docker Sandboxes zu benutzen, weil ich den Sicherheitsaspekt, der ist mir wichtig, den möchte ich gerne mitnehmen.
Aber ich nehme dankend an, dass ich mich nicht selber um die ganze Infrastruktur kümmern muss, dass ich nicht selber das ganze Setup machen muss, sondern dass ich im Wesentlichen SBX tippe und den ganzen Rest erledigt.
Infrastruktur, die ich nicht selber verwalten muss für mich.
Und stellen wir uns jetzt mal vor, wir sind in einem Entwicklungsprozess für ein bestimmtes Projekt und ich habe mein Projektverzeichnis mit Code, mit einem Git-Repository im Grunde.
Und wie arbeite ich jetzt mit den Dateien?
Also arbeite ich jetzt mit einer Kopie in der virtuellen Maschine und ich muss dann das immer rüberkopieren lassen, damit ich das sozusagen einchecken kann?
Oder arbeite ich mit Git generell direkt drin in der virtuellen Maschine?
Aber das würde ja dann irgendwie den Sicherheitsaspekt wieder aufweichen.
Was habt ihr da so für Erfahrungen gemacht?
Wie arbeite ich da mit meinen Dateien am besten in der VM?
Also eins der Convenience Features, wie Stefan das ja eben genannt hat, ist, du kannst im Prinzip in deinem Projektverzeichnis mit SBX eine VM starten, also SBX Run und dann gibst du an, welchen Agent du benutzen möchtest, Cloud oder Codex oder auch noch, es sind noch andere vorbereitet.
Und dann wird on the fly, wenn es noch keine VM gibt, die zu diesem Verzeichnis gehört, eine angelegt.
Und dann werden auch ein paar Dinge einfach schon direkt eingerichtet.
Also zum Beispiel ist es so, dass das Projektverzeichnis in die VM gemountet wird.
Das heißt, du hast das Projektverzeichnis...
Innen wie außen genauso.
Und da finde ich zum Beispiel, das ist noch ein netter Gimmick, dass der Pfad gleich bleibt.
Also jetzt, ich arbeite zum Beispiel sonst auf Mac.
Das heißt, mein Home-Verzeichnis ist irgendwie slash users slash Michel.
Und dann habe ich in der VM, auch wenn das eine Linux-VM ist, eben auch diesen Pfad.
Und dann dort unter, was weiß ich, dev und dann irgendwie Projektname.
die Dateien, das heißt, wenn ich zum Beispiel Config-Files für jetzt lokale Server zu starten oder irgendwas in diesem Verzeichnis liegen habe, also auch wenn die nicht in Git committed würden, dann sind die sowohl für den Agent verfügbar als auch für mich außerhalb der VM.
Also dieses Verzeichnis ist einfach geshared.
Das heißt natürlich, man muss Dann auch wieder ein bisschen aufpassen, also wenn man jetzt zum Beispiel ein .env-File mit irgendwelchen Secrets in dem Projektverzeichnis liegen hat, dann müsste man sich da was für einfallen lassen, wenn man vermeiden möchte, dass der Agent das lesen kann.
Also standardmäßig wäre das dann auch für den Agent erreichbar.
Und was du vorhin gesagt hast, also mit Git, also Grundsätzlich, meine Git funktioniert ja erstmal auch lokal zum Committen und das heißt, du kannst durchaus den Agent mit Git arbeiten lassen.
Du kannst sogar, wenn du das möchtest, halt den Agent auch ausstatten mit Credentials für GitHub oder GitLab oder was auch immer du benutzt.
Und dann gibt es eben dafür...
Mechanismen, wie man das steuern kann.
Aber letzten Endes ist es so, wenn du jetzt deinem Agent erlaubst, in einem bestimmten Projekt für dich Commits zu machen und die auch zu pushen, dann musst du dir darüber halt bewusst sein, dass der das dann eben auch macht.
Oder machen kann, zumindest.
Was du gerade beschrieben hast, Michael, ist der Standardmechanismus?
dass ich eben das Verzeichnis tatsächlich komplett drin habe.
Es gibt noch einen weiteren Mechanismus, bei dem in deiner Sandbox ein eigenes Git-Remote im Endeffekt angelegt wird und du das von außen dann nutzen könntest, um von dem, was in der Sandbox ist, Dinge nach außen zu pullen und dann selber Änderungen vorzunehmen.
Damit habe ich allerdings selber null Erfahrung.
Ich habe das nie benutzt.
Es gab auch...
vor ein paar Monaten mal das Feature des verschiedenen Sandboxes Git Worktrees benutzt haben.
Aber das ist so ein bisschen, was wir reden über 0.3 irgendwas Version gerade.
Also Feature tauchen auch mal auf und verschwinden wieder.
Dieses Git Worktree Feature ist dann auch irgendwann wieder weggegangen zugunsten eben dieser Möglichkeit, innerhalb des Containers ein eigenes Git Remote anzulegen.
Weiß ich nicht, Michael, hast du das mal benutzt?
Ich habe das noch nie eingesetzt.
Nein, habe ich bisher nicht.
Also da wurde ich auch schon mal bei einem Vortrag nachgefragt.
Aber also du hast schon recht, es ist der Standardmodus.
Aber ich muss sagen, also für mich persönlich, ich kenne glaube ich auch einige Features von Docker Sandboxes gar nicht, weil der Default für mich echt super gut funktioniert.
Also ich ändere daran extrem wenig.
Deshalb zum Beispiel, was ich eben gesagt habe, dass die Pfade innerhalb und außerhalb gleich sind.
Ich finde das total praktisch, mir hilft das.
Ich wäre aber nie auf die Idee gekommen, das mir selber jetzt so zu konfigurieren.
Also auch auf deine Frage hin, mit dem könnte ich mir nicht mit KVM oder mit irgendwas das selbst bauen.
Hat ja Stefan schon gesagt, da könnte man.
Aber wahrscheinlich hätte ich auch nicht unbedingt all diese Entscheidungen so getroffen.
Und ich finde sie super praktisch, also die meisten, so wie sie sind.
Also das mit diesen anderen Modus habe ich noch nicht benutzt.
Geht mir ganz genauso.
Ich benutze praktisch alles in den Default-Einstellungen und kenne einen Teil der Features, die in der Doku stehen, auch nur, weil sie in der Doku stehen und nicht, weil ich sie selber schon mal benutzt hätte.
Das klingt so, als wäre Docker Sandboxes irgendwie noch ein frisches und neues Tool und noch gar nicht so stabil?
Das Kernfeature-Set ist schon stabil.
Es gab eben solche Dinge wie den Worktree-Modus, der in, ich glaube, ich habe mit irgendeiner 0.21-Version oder irgendwas in dieser Größenordnung angefangen und wir sind jetzt bei 0.37, 38, irgendwas in dieser Gegend.
Die werden relativ häufig neu released.
Und dann kommen Feature dazu, von denen ich denke, ah ja, gut, klingt nett, brauche ich aber nicht.
Und mein Feature-Set, das ich habe, hat sich ein Stück weit erweitert im Laufe der Zeit.
Anfänglich gab es nur ein Verzeichnis, das ich in die Sandbox hineinreichen konnte.
Dann ist später die Möglichkeit dazu gekommen, dass ich auch noch weitere Verzeichnisse zusätzlich in die Sandbox aufnehmen kann.
Bei denen aber vielleicht sagen kann, dass die nur lesende Zugriffe erlauben und ich keinen Schreibzugriff auf diesen Verzeichnissen habe.
Das ist etwas, was ganz nützlich ist.
Und ein paar Dinge ändern sich eben auch teilweise.
Also ursprünglich, als ich damit angefangen habe, war alles noch experimental.
Jetzt ist es, glaube ich, Early Access.
Und andere Dinge sind aber eben als experimental markiert.
Und nach der Erfahrung bisher würde ich sagen, das, was experimental ist, kann sich auch nochmal ändern von den Dingen, die man sieht.
Ich bin mir da nicht hundertprozentig sicher, aber ich glaube, also...
Ich glaube, Docker Sandbox ist jetzt nicht mehr Early Access, also das Tool an für sich, sondern ich meine, das sei jetzt einfach so offiziell.
Es gibt Features, die sind Early Access.
Aber als wir angefangen haben, das zu benutzen, da war das ganze Tool in dem Status.
Genau, was halt passiert ist, also wenn du sagst stabil, da muss man überlegen, was man mit stabil meint.
Also ich finde, es ist jetzt mir noch nie gecrashed.
Also es ist schon voll okay von der Stabilität zur Laufzeit sozusagen.
Aber es ändert halt viel.
Also es ist relativ volatil, dass neue Sachen hinzukommen.
Oder hier neulich stand, also man kennt das ja mit den Halluzinationen von den Agents irgendwie, dass die dir was erfinden.
Die Neulich stand was in der Doku, aber das ging noch gar nicht.
Also selbst mit der neuesten Version, das Flag war einfach nicht da.
Und das, also es geht halt vieles relativ schnell.
Aber wenn man dann ein paar Tage wartet, dann hat sich das dann auch eingependelt.
Stefan, du hattest neulich eine interne Präsentation gehalten, wo wir schon mal sehen konnten, wie du persönlich mit Docker Sandboxes arbeitest.
Und ein Feature, was mir da aufgefallen ist, ist die Überwachung des Netzwerkverkehrs.
Magst du das Feature einmal erklären und wozu man das braucht?
Ja, gerne.
Warum es so toll ist vor allem?
Also um die virtuelle Maschine, die in dieser Docker-Sandbox drumherum läuft, wird mit Betriebssystemmitteln das Netzwerk abgedichtet.
Sandbox und der Welt da draußen steht und ich kann diesen Proxy konfigurieren.
Ich kann in diesem Proxy sagen, auf welche Hostnames darf denn überhaupt ein Zugriff gemacht werden, auf welche IP-Adressen darf zugegriffen werden und dann gibt es von Docker-Sandboxes ausgehend so drei verschiedene Policies, mit denen man erstmal per Default starten kann.
Es gibt die Policy, ich erlaube alles.
Es gibt die Policy, ich erlaube gar nichts und dann gibt es noch irgendwas, was dazwischen liegt, was sie Balanced nennen, in dem bestimmte Dinge, von denen die Leute, die Docker-Sandboxes machen, der Meinung sind, dass das sinnvoll ist, die Dinge dort reinzuschreiben, die dann schon mal per Default erlaubt sind.
Aber all diese Regeln kannst du sowohl global anpassen und tatsächlich zur Laufzeit anpassen.
Das heißt, ich sehe...
Von außen kann ich sagen, wenn Ihnen aus der Sandbox ein Netzwerkzugriff nicht geklappt hat, irgendwas nicht funktioniert, kann ich außen lesen, welche Zugriffe hat denn diese Sandbox versucht, kann mir überlegen, ob ich diese Zugriffe erlauben möchte, kann dann eben sagen, ich erlaube den Zugriff auf diesen Host für diese eine Sandbox oder global und dann sagen, versuch es einfach nochmal innerhalb dieser Sandbox und dann kommt es im Normalfall auch raus und das funktioniert, ohne dass ich irgendwas groß neu starten muss.
Für mich habe ich ein paar Dinge tatsächlich nicht.
Bin selbstverständlich mit Du darfst gar nichts gestartet und habe dann aber sehr, sehr schnell festgestellt, dass es schon so einen Standardsatz gibt, den ich auf jeden Fall in jeder Sandbox freigeben möchte.
Die Basis all dieser virtuellen Maschinen ist ein Ubuntu Linux.
Also habe ich die Paketquellen für Ubuntu Linux freigegeben und dort, wo eben Updates heruntergeladen werden möchten.
Wenn ich einen bestimmten Agent verwende, dann wird dieser Agent möglicherweise mit einem Server sprechen möchten.
Also ich nutze Claude-Code innerhalb der Sandbox.
Dann muss ich für die Sandboxes, in denen ich Claude-Code benutze, das sind nicht alle, muss ich dann auch den Zugriff auf das Anthropic API erlauben, damit Claude eben sprechen kann mit seinem Model, mit dem es gerne sprechen möchte.
Solche Dinge stelle ich.
Naja, mal so aus dem Bauch raus global ein und mal tatsächlich für eine einzelne Sandbox.
Aber es ist tatsächlich so, dass ich mehr als eine Sandbox habe und sie dann auch projektspezifisch konfiguriere.
Machst du das wirklich so, dass du dann nur für die Sandboxen, wo du Cloud Code benutzt, die Entropic API freigibst?
Ja, aber das ist ein Kit.
Wir kommen irgendwann später dazu, was Kits sind, aber du kannst den Kits sagen, worauf du Zugriff geben möchtest.
Und bei den Sendboxes, wo ich Cloud-Code benutzen möchte, binde ich ein Kit ein, das die richtigen Netzwerkzugriffe erlaubt.
Aluminium auf diesem Boot ist ein bisschen dicker als bei anderen Leuten.
Wenn du schon Kits sagst, warum reden wir nicht jetzt schon über Kits?
Also sind das sowas wie Plug-ins?
Also ich würde sagen, das sind so...
Also du kannst halt über ein Kit erreichen, dass bestimmte Dinge quasi zu...
Also du musst jetzt kein eigenes Image bauen.
Das wäre ja...
Das könntest du auch tun, glaube ich.
Habe ich auch noch nie gemacht.
Aber du könntest ja jetzt auch sagen, nee, so wie das Image jetzt irgendwie von Docker quasi vorgeschlagen wird, so passt mir das nicht.
Aber mit den Kits ist es halt deutlich einfacher, weil du kannst bei dem...
Standard-Image bleiben und kannst dann halt additiv irgendwelche Dinge über so ein Kit hinzufügen.
Und damit dann zum Beispiel, so wie Stefan das gerade gesagt hat, mit den Netzwerkzugriffen, aber das könnte auch sein, dass du jetzt zum Beispiel Skills für den Agent hinzufügen möchtest und das kannst du dann eben über Über ein Kit könntest du das machen, dass du dein Default-Skillset da irgendwie mit reinnimmst?
Genau, du kannst Dateien reinkopieren.
Du kannst auch sagen, ich möchte bestimmte Software installieren.
Ich möchte bestimmte Dinge zu Start meiner Sandbox oder bei der Installation der Sandbox ausführen.
Ich habe solche Kits für...
die .NET brauchen, wo ich dann einfach ein Kit habe, das mir das .NET SDK installiert in der richtigen Versionsnummer, die ich brauche.
Und ich habe ein anderes für Java-Projekte, die ich einbinde.
Und solche Dinge, damit ich eben nicht überall ein OpenJDK in einer bestimmten Version in der Sandbox habe, mache ich das nicht global, sondern eben für jede Sandbox einzeln einmal.
Das ist ja ein Debian-basiertes System.
Das sind einfach im Wesentlichen zwei APT-Kommandos, die man in das Kit reinschreibt, um die richtigen, vielleicht sind es auch fünf, die richtigen Paketquellen einzubinden, zu sagen, mach mal ein Update, installiere bitte das.
Und dann sind die Dinge da.
Du kannst Dateien kopieren, das, was Michael mit Skills sagte.
Du kannst Netzwerkzuregeln, du könntest Secrets hinterlegen, nochmal ein anderes Thema.
Da gibt es schon Möglichkeiten, die zusammengehen.
Und was du eben sogar tun kannst, ist deine eigenen Agents erfinden.
Also wir haben den Begriff des Agents jetzt schon ein paar Mal gehabt.
Der ist auch zentral bei Docker.
Das ist halt eigentlich der Prozess, der gestartet wird, wenn ich die Sandbox starte.
Da gibt es dann vordefinierte Agents für die meisten großen Agentic-Coding-Umgebungen, die in der Shell laufen.
Also Cloud-Code oder Codex oder Copilot oder was man sich da so vorstellen kann.
Aber es ist auch möglich, seine eigenen Definitionen von Agents anzugeben.
Es gibt einen.
Skills-Contrip-Repository, wo Leute ihre Skills zur Verfügung stellen als Open-Source-Projekte.
Und darin findet sich zum Beispiel was für PyDev, also für einen anderen Harness, mit dem ich beliebige Modelle unten drunter stecken kann, damit ich diesen als Agent starten kann.
Und ganz, ganz klein, Shell ist ein Agent.
Also da startet dann einfach eine Bash und die ist eingebaut.
Dafür brauche ich kein Kit, sondern darauf aufbauend kann ich eben all die anderen Dinge tun, wie das, was du über deine NPM-Updates beschreibst.
Da brauchst du eigentlich nur die Shell, in der du dann NPM-Install oder NPM-Update oder was auch immer sagst, um das auszuprobieren.
Ja, ich hatte gar nicht daran gedacht, dass, also ich dachte, wenn ihr jetzt über VMs sprecht, dass ich da halt einfach eine Konsole aufmache, eine SSH-Verbindung zu dieser VM und dann kann ich dort halt wie in jedem Betriebssystem einfach Dinge nachinstallieren.
aufrufen und so weiter.
Aber es klingt jetzt eher danach, als wäre das sehr abgeschottet und als bräuchte man Kits, um Dinge nachzuinstallieren.
Ist das korrekt?
Habe ich das falsch verstanden?
Nee, brauchst du nicht.
Also du könntest dich auch einfach, also ähnlich wie bei Docker, also jetzt nicht die Firma Docker, sondern das Tool, kannst du halt auch mit exec zum Beispiel, also sbxrun ist das, womit du eigentlich normalerweise eine von diesen VMs startest und dann wird eben diese, wie Stefan eben sagte, typischerweise der Agent ausgeführt und es ist dann tatsächlich so, dass sie die Bash sogar oder die Shell als einen möglichen Agent beschreiben.
Da hängt aber dann auch noch dran, dass das Base-Image verschieden ist.
Wenn du jetzt spxrunclawed aufrufst, dann nimmt er ein anderes Base-Image.
Also dann nimmt er halt eins, wo clawed installiert ist.
Wenn du spxrunclawed aufrufst, dann nimmt er halt ein Image, wo copilot installiert ist.
Ich weiß nicht genau, wie die Unterschiede noch sind, aber das Image ist verschieden.
Und eben shell ist dann auch wieder ein anderes Image, der ist vielleicht wahrscheinlich gar kein Agent sonst installiert.
Aber du kannst natürlich mit spxexec zum Beispiel in eine bestehende VM, dich einfach wie einloggen und hast dann dort ein Terminal.
Und dann kannst du auch dort einfach abget, was auch immer tun.
Und das meinte ja Stefan mit ganz am Anfang, es ist einfach eine VM, also die hat ein State.
Die hat eine Disk oder ein Disk-Image.
Und wenn du in der VM etwas veränderst und die dann schließt, dann startest du die beim nächsten Mal und dann bist du wieder bei dem Zustand, den du halt vorher hattest.
Also wenn du einmalig irgendwelche Dinge in der VM nachinstallierst, dann sind die zwar dort, aber die bleiben dann halt so, wie sie sind.
Also das Thema mit den Updates, da können wir vielleicht gleich nochmal drüber reden, das fände ich eben spannend, wie Stefan das macht.
Aber Ähnlich ist es eben auch jetzt mit den Skills.
Wenn man die Skills, die könnte man sich ja auch einmal rüber kopieren.
Und wenn man das macht, dann ändern die sich aber nicht mehr.
Also bei mir ist das zumindest so, dass ich an einigen Skills immer noch mal was nachschärfe oder die halt in irgendeiner Form weiterentwickle.
Und dann, wenn ich jetzt, also ich habe sehr viele von diesen VMs, weil ich Das normalerweise, weil ich an vielen Projekten parallel arbeite und dann typischerweise für jedes Projekt eine eigene VM habe.
Und dann ist es sehr schwierig, das nachzuhalten, wo jetzt welche Version von was hin kopiert wurde.
Und diese Kids, wenn man halt die Kids einbindet, dann kann man das auch erreichen, dass der quasi das beim Starten immer wieder rüber kopiert.
Ah, okay, verstanden.
Dankeschön.
Genau, und du kannst natürlich Software installieren ohne ein Kit, dass ich sowas wie das .NET SDK mit einem Kit installiere.
Einfach damit ich das nicht siebenmal machen muss, damit ich nicht siebenmal die gleichen Kommandos eintippen muss, sondern das einmal irgendwo hingeschrieben habe, wie es geht.
Das, was bei Kits noch nett ist, fällt mir gerade ein.
Das ist nicht unbedingt mir eingefallen, sondern es ist mir im Gespräch mit einem Kollegen kam das auf, dass er sagte, das Nette daran ist, dass die...
composable sind, dass ich sie miteinander kombinieren kann.
Wenn ich sowas mit Containern machen würde, dann habe ich das Base-Image, da ist Rust drin, aber manchmal brauche ich vielleicht Rust und Python und Node.
Dann fange ich an, Probleme zu haben, die Dinge zusammenzustecken.
Bei sowas wie Sandboxes kann ich aber die drei Kits, die Rust und Node und Python installieren mit den passenden Modulen, kann ich eben die drei Kits einfach zusammenfassen und dann habe ich die Dinge miteinander komponiert.
eigenständiger und damit auch leichter als Bausteine zu nutzen, als das Layer wären, die ich einem Docker-Container obendrauf lege.
Ja, Michael, du wolltest doch jetzt davon fragen.
Ja, genau, also wie machst du das denn mit den Updates?
Weil ich habe halt das Gefühl, wenn ich, also vielleicht liegt es auch daran, dass ich so viele VMs habe, aber Und so wie ich das handhabe, muss ich eigentlich in jeder dieser VMs, also wenn ich die jetzt über längere Zeit benutze, dann irgendwann mal Updates machen.
Ja, geht mir auch so.
Mache ich auch tatsächlich von Hand, muss ich zugeben.
Und das ist, ich habe wahrscheinlich weniger VMs als du.
Das liegt ein Stück weit auch daran, dann kann ich die Frage zurückgeben, wie managst du eigentlich deinen Festplattenplatz?
Weil Micro-VM klingt viel kleiner, als es am Ende tatsächlich ist.
Root-Dateisystem hat, glaube ich, 20 GB per Default für jede einzelne VM, die ich da starte.
Und die liegt dann als Snapshot auf meiner Festplatte.
Und mir ist es irgendwann vor zwei, drei Wochen passiert, dass mein Home-Verzeichnis, bei dem ich das Linux-Volume zu klein bemessen hatte, einfach voll war, weil die ganzen Snapshots drin lagen.
Und dann habe ich aufgeräumt.
Und deshalb sind es jetzt gerade etwas weniger VMs, als ich vorher gehabt habe.
Natürlich habe ich noch andere Dinge geändert, damit es zukünftig nicht mehr passiert.
Hoffe ich zumindest.
Aber wie machst du das bei ganz, ganz vielen V-Ims mit dem Festplattenplatz?
Weil das, was mir gerade fehlt, ist ein Räum mal alte Snapshots weg Feature.
Tatsächlich, ich glaube, das gibt es in der Form nicht.
Ich habe den Eindruck, die belegen viel, viel mehr Plattenplatz, als sie bräuchten.
Also, ja, also mal der Reihe nach.
Also ich müsste jetzt nachschauen.
Ich denke, ich habe...
Also ich habe auch hier neulich aufgeräumt, weil auch meine Disc vollgelaufen ist, aber ich glaube, es lag an was anderem.
Und nicht nur an den VMs.
Und ich hatte aber zuerst die VMs im Verdacht, weil der auch angezeigt hat, ich hätte 980 GB VMs oder sowas, hat mein Feinde angezeigt.
Es scheint aber so zu sein, ich musste dann einfach aufräumen und hatte keine Zeit für Forensik.
Aber es scheint so zu sein, dass diese Angabe falsch war.
Also ich hatte wahrscheinlich keine 980 Gigabyte VMs, sondern da waren einige, ich weiß nicht, ob der Hardlinks benutzt oder was er da macht.
Jedenfalls, ich glaube, diese Angabe war falsch.
Aber du hast total recht.
Eine VM belegt relevant Festplattenplatz.
Ich denke, Micro bezieht sich auch eher auf den sozusagen Footprint zur Laufzeit und weniger auf den Disk Space.
Absolut.
Und also ich habe jetzt diese Gelegenheit genutzt und auch mal VMs weggeworfen, die ich gar nicht mehr benutze oder die ich lange nicht mehr benutzt habe.
Und letzten Endes, wenn man zum Beispiel diese Kids anlegt, dann sind die VMs im Prinzip auch reproduzierbar.
Also wenn ich die...
später wieder starte in dem gleichen Ordner und zum Beispiel dann ein Kit angebe oder vielleicht auch nicht, wenn mir der Default reicht, dann kriege ich schon etwas anderes wie das, was ich vorher hatte.
Also es ist ja so, dass durch die Updates von Docker Sandbox und das ist eigentlich auch spannend, ich bin mir nicht sicher, ob es genau synchronisiert ist, dass die Base Images auch immer nur ein Update bekommen, wenn ein neues Update des SBX-Tools kommt.
Habe ich mir noch nie angeschaut.
Aber wenn ich jetzt, sagen wir mal, eine VM angelegt habe vor zwei Monaten und würde die jetzt löschen und die dann mit dem gleichen Kommando neu anlegen, habe ich nicht exakt die gleiche VM, sondern ich habe ziemlich sicher eine neuere Version, also eine neuere Space-Image für eine sehr ähnliche VM, die aus meiner Erfahrung auch das Gleiche tun wird.
Aber In Details kann sich das halt unterscheiden.
Finde ich jetzt nicht schlimm.
Und bei den 10 bis 15 VMs, die ich habe, ja, also ich komme damit zurecht mit dem bisher mit dem Disk Space.
Ich denke schon, dass das so 20 bis 20, 30 GB pro VM sind.
Ja, aber was mich eben, also was mich eher dazu anleitet oder was mich eher dazu bringt, die öfter mal wegzuwerfen, das ist wirklich das mit den Updates.
Also wenn ich sie halt wegschmeiße und sie neu anlege, dann weiß ich a, dass ich darin quasi keinen Shadow State, also nicht irgendwelche Dinge habe, die ich eigentlich brauche, aber die mir gar nicht mehr so bewusst sind.
Das würde ich ja eigentlich auch gerne vermeiden.
Ich will ja meine wertvollen Dinge in dem Projektverzeichnis oder in irgendwelche Dinge habe, wo ich auch ein Backup von habe und nicht nur auf meiner lokalen Disk.
Und Updates mache ich schon, aber ich finde es eben bei der Menge an VMs mühsamer, die Updates wirklich seriös zu machen, als dann eher so eine Art Hygiene zu entwickeln und die VMs halt mal wegzuwerfen.
Und das vielleicht als Gelegenheit zu nutzen, auch Kids zu erstellen, da wo ich Anpassungen brauche, wenn ich das nicht sowieso schon gemacht habe.
Hört sich richtig an.
Sollte ich auch tun.
Anja, du hattest eben gesagt, du hast dir dann vorgestellt, du startest die VM und dann gehst du da per SSH drauf oder so etwas in der Form.
Tatsächlich ist die User Experience, du gehst in dein Terminal, du trittst da drin SBX Run und den Agent, den du haben möchtest, vielleicht noch ein paar andere Kommandozeilen-Parameter und dann startet halt der Agent in deinem Terminal.
Das heißt, es ist das Kommandozeilen-Interface deines Agents, das in deinem Terminal läuft.
Nicht so, dass du jetzt noch einen extra Prozess benötigst, um da reinzugehen.
Das, was aber die virtuelle Maschine nicht hat, ist irgendeine Art von UI im Normalfall.
Das heißt, für Menschen, die die Desktop-Anwendung von Cloud oder ChatGPT oder sonst irgendwas verwenden, bietet sich die Sandbox nicht unbedingt an, weil ich da nicht vernünftig reinkomme, um damit irgendwas zu tun.
Also das ist tatsächlich...
glaube ich momentan der Anwendungsfall eher Menschen, die keine Hemmungen haben, auf der Kommandozeile Dinge zu tun und mit dem Text UI ihres Agents zu kommunizieren.
Es gibt, glaube ich, in den neuesten Versionen tatsächlich auch die Möglichkeit, per SSH reinzukommen, also tatsächlich sauber per SSH in den Container reinzukommen, wenn man das haben möchte, dass da ein SSH-Demon drin gestartet wird.
Das habe ich aber selber noch nie benutzt.
weil ich bisher auch keinen Anwendungsfall dafür gehabt habe.
Aber die Möglichkeit existiert grundsätzlich.
Ich gehe davon aus, dass es auch keine wirklichen Integrationen für EDEs gibt, oder?
Also man weiß ja, dass EDEs auch ihre eigenen Chatprogramme haben, worin sie dann beispielsweise Cloud oder Chat-GPT und so weiter zur Verfügung stellen.
Das bedeutet, auch diese Graphical User Interfaces in meine EDE kann ich nicht unbedingt mit Docker-Sandboxes verbinden, oder?
Doch, kannst du schon.
Also je nachdem, was du für eine IDE nutzt.
Aber jetzt, also ich benutze das nicht mehr wirklich.
Ich habe schon, also ich mache viel Java, ich habe aber schon eine Weile meinen IntelliJ, oder ich benutze es wirklich nicht mehr so häufig, weil einfach der Agent viel macht.
Aber wenn ich Du kannst halt viel machen, auch über einen MCP-Server.
Also zum Beispiel die IDEs stellen jetzt häufig MCP-Server zur Verfügung, worüber dann du eine Integration hinbekommst.
Aber das, was Docker Sandbox an Integration nennt, das gibt es, glaube ich, nur für VS Code und für Cursor oder sowas.
Aber auch das habe ich noch nie genutzt.
Aber das ist ja schon mal ein Anfang.
Ich bin tatsächlich vollständig auf der Shell unterwegs in dem Umfeld.
Das heißt, tatsächlich nutze ich gelegentlich doch noch ziemlich viel Rider in der .NET-Entwicklung, was JetBrains IDE für .NET ist, und starte das dann in dem Shell-Fenster.
Und dann füllt es darin aus.
Es gibt dann gelegentlich mal Probleme, dass...
Wenn der Agent Dinge geändert hat, dass Rider nicht alles mitbekommen hat zur richtigen Zeit oder mit einem anderen SDK kompiliert worden ist, weil da drin was anderes ist als draußen installiert ist oder sowas, muss es mal ein Refresh bekommen, dann geht das.
Aber an ganz vielen Stellen geht es mir dann auch ähnlich wie Michel, dass die IDE so ein Stück weit auch in den Hintergrund tritt.
Ich bin so oder so immer eher ein Mensch gewesen, der nicht so viele Feature der IDE genutzt hat.
Und das, was jetzt noch übrig ist, kann ich auch genauso gut in Emacs machen.
Das stimmt, ja.
Da ist es halt praktisch, also wenn man jetzt zum Beispiel das Terminal in der IDE benutzt, um in dem Terminal SBX mit einem Agent zu starten, dann ist das halt auch wieder praktisch mit den Pfaden, dass die innerhalb und außerhalb gleich sind.
Weil wenn ich jetzt, also die IDEs parsen ja quasi das, was im Terminal passiert.
Und wenn ich dort einen Pfad von irgendeiner Datei sehe, dann kann ich da halt mit Control oder was auch immer auf dem Betriebssystem halt en vogue ist, kann ich da im Prinzip draufklicken und dann macht die IDE diese Datei auf.
Und das geht ja auch, das kann ja quasi rein dann die IDE.
Also dafür muss SBX ja nichts tun.
Aber diese Geschichten, also ich gehe davon aus, das hat aber eigentlich auch nichts mit SBX zu tun, sondern eher insgesamt mit den Agents.
Sowas wie ein Refactoring oder das Umbenennen von von irgendeinem Namen in einer kompilierten und typisierten Sprache.
Das war über die Agents ja immer ziemlich mühsam, weil die haben ja kein Linter, die haben kein Syntax-Tree normalerweise, sondern machen das alles textbasiert.
Und das geht jetzt zum Beispiel zum Teil über ...
MCP-Server, die die IDE zur Verfügung stellt.
Also das hat aber eigentlich auch eben nichts mit SBX zu tun.
Das würde auch mit dem Agent einfach so gehen, wenn der hier im Terminal läuft und nebendran ist die IDE.
Und das kann ich aber in SBX mehr oder weniger genauso machen.
Lass uns doch einmal Links zu diesen Projekten in den Show Notes zusammenfassen.
Ich denke, das ist für alle interessant.
Für mich zumindest.
Ja, gerne.
Ja, das klingt doch schon gut.
Ich kann mich noch an ein Feature so dunkel erinnern.
Um meine Secrets zu schützen, kann ich sie von außen reingeben, ohne dass der Agent die eigentlich sieht, wie genau funktioniert das.
Also so Header-Manipulation, oder?
Wie war das?
Genau, also der Proxy, von dem ich eben gesprochen habe, ist für eigentlich alles ein Machine-in-the-Metal-Proxy.
Das heißt, selbst wenn ich aus dem Agent heraus einen HTTPS-Zugriff mache, bricht der Proxy die verschlüsselte Kommunikation auf.
Der hat in das Basis-Image im Zweifel sich selber als Trusted Certificate Authority eingetragen, sodass er einfach für alles gültige Zertifikate ausstellen kann.
Wenn wir dann kein Certificate Pinning haben, dann komme ich da schon durch.
Und dann sieht er den HTTP-Request und kann damit Dinge tun.
Und dann kann ich eben außen sagen, dass wenn er in bestimmten HTTP-Headern Platzhalter die ihm sagen, hier müsste jetzt mein Secret eingefügt werden und ich konfiguriert habe, wie dieses Secret heißt, dass er das dann dort einfügt.
Also das ist so im Wesentlichen der Mechanismus.
Das heißt, das Tooling innen drin müsste wissen, was es an der richtigen Stelle hinzufügen muss an Platzhalter.
Dafür werden dann Environment-Variabeln in der Sandbox erzeugt.
Da steht dann aber replaced by proxy oder sowas drin.
Aber du sagst halt, Dein Curl-Aufruf, setz mal hier in den Authorization-Header den Wert dieser Environment-Variablen ein.
Dann sieht es für Curl so aus, als würde in der Environment-Variable vielleicht mal ein Basic-Auth oder tokenbasierte Authentisierung drinstecken.
Und der Proxy ersetzt dann quasi diesen Platzhalter durch das Secret, das in dem Proxy drin hinterlegt ist.
Das ist so der einfache Mechanismus für...
Komplexere, bestimmte vordefinierte komplexere Dinge, die OAuth 2 beispielsweise angehen, kann dieser Proxy eben auch die Redirects-URI für OAuth 2 anbieten.
Also um jetzt nicht zu technisch zu werden, im Wesentlichen fängt der Proxy das ausgestellte Token bei einem OAuth 2-Flow ab und kennt dann das Token aber nicht innen drin.
Das heißt, wer nicht?
Für Anthropic geht das irgendwie schon sehr, sehr lange.
Wenn ich in Claude ein Slash-Login sage, dann gibt er mir den Link, mit dem ich, öffnet auch tatsächlich meinen Browser, damit ich freigebe, dass tatsächlich mein Token jetzt weitergegeben werden soll an Claude in Shell drin.
Und das dabei ausgestellte Token landet aber im Proxy.
Das landet nicht in der Sandbox, sondern das Token landet nur im Proxy.
Die Sandbox benutzt den Platzhalter.
nicht das echte Token und der Proxy ersetzt den Platzhalter durch das echte Token an dieser Stelle.
Damit habe ich so ein Stück weit den Zugriff auf meine Secrets verschoben.
Ich muss nicht mehr dem Code, der in der Sandbox liegt, vertrauen.
Dafür muss ich jetzt Docker Incorporated vertrauen, denn die haben die Secrets in dem Proxy.
Und auch da kann man sicherlich darüber diskutieren, ob die selbstgestrickte Lösung, wenn ich sie denn hätte, am Ende nicht mehr Souveränität und noch vertrauenswürdiger bedeuten würde, als dass ich so etwas einem kommerziellen Produkt, was es am Ende ist, überlasse, dessen Quelltexte ich auch nicht einsehen kann.
Ah, es ist also kein Open-Source-Projekt?
Es setzt sich aus einigen Open-Source-Komponenten zusammen, aber das komplette Ding ist nicht wirklich Open-Source.
Das, was bei GitHub ist, ist, dass es ein GitHub-Projekt dafür gibt.
Da drin wird...
der Issue-Tracker benutzt und die Releases können dort runtergeladen werden, aber der eigentliche Quelltext von Docker-Sandbox ist nicht da.
Das sind Kombinationen von offensichtlich existierenden Dingen, also was auch immer an Aufsatz auf KVM genutzt wird.
Unter Linux ist ein Open-Source-Projekt, auf dem dann die Micro-VM läuft, aber da sind auch eine ganze Menge Dinge an Code dabei, die eben nicht öffentlich sind.
Könnte es so aussehen, dass es irgendwann hinter einer Bezahlschranke verschwinden wird, dieses Tool?
Was denkt ihr?
Das hatten wir am Anfang ja so ein bisschen befürchtet, als das Ganze noch Early Access war.
Und eben, es ist kein Open Source.
Aber so wie es jetzt von Docker kommuniziert wurde, ist das Tool eigentlich frei.
Also da gab es auch schon gewisse Anstöße, weil man das nicht benutzen kann.
ohne einen Account von Docker.
Also man muss bei Docker einen Account anlegen, man muss nichts zahlen, aber man muss auch regelmäßig, wenn man SBX aufruft auf der Kommandozeile, dann passiert es immer wieder, dass man quasi das auch so wie ...
Stefan das gerade beschrieben hat von dem Entropic-Login, dass dann quasi aus der Kommandozeile raus ein Browser aufgeht und man dort eine Bestätigung oder da muss man eingeloggt sein bei Docker mit dem Browser und dann muss man dort das freigeben.
Also das Tool selbst kann man wirklich nicht benutzen, ohne dass man zumindest preisgibt, wer man ist.
Und das...
Jetzt auch bei uns, bei einigen Kollegen ist das nicht so wirklich gut angekommen.
Kann ich auch erstmal nachvollziehen.
Also richtig offen wäre natürlich besser.
Aber ich glaube, dass die Standardfeatures, über die wir jetzt gesprochen haben, alle frei bleiben.
Zumindest war das die letzte Kommunikation, auch für kommerziellen Einsatz.
Und was sie halt verkaufen wollen, ist so, wie nennen sie das?
Also so ein Enterprise-Feature haben sie quasi, wo man erreichen könnte, dass dass man zentral irgendwo was konfiguriert, wie auf den Arbeitsplatzrechnern halt die Sandboxes irgendwie zum Beispiel bezüglich Netzwerk-Policies konfiguriert werden oder sowas.
Genau, also Governance-Zeug im Endeffekt, dass du sagen kannst, ich fasse die Menschen, die für meine Firma arbeiten, zu einem Team zusammen und dann kann ich entscheiden, wer aus meinem Team darf welche.
Dinge ausführen darf, tatsächlich worauf im Netzwerk zugreifen.
Ich glaube, es gibt auch noch so Dinge wie teamweite Kits, die man dann teilen könnte, die dann nicht öffentlich sind und nicht nur lokal auf dem Rechner liegen.
Also meine Kits sind lokal.
Es gibt dieses Contrib-Ding, das Open-Source ist.
Aber es gibt dann eben auch die Möglichkeit, im Team solche Kits zu teilen und dann...
Dinge untereinander besser verbreiten zu können.
Und vor allen Dingen, um viel, viel stärker zu reglementieren, wer welche Feature von Docker-Sandboxes nutzt.
Das sind aber alles Dinge, die mich überhaupt nicht interessiert haben.
Deshalb habe ich auch überhaupt nicht angeguckt, was damit im Detail nachher funktioniert oder nicht funktioniert.
Ja genau, Governance, das war das Wort, was ich eben gesucht habe.
Aber also ein Feature gibt es, was scheinbar da drin steckt.
Und das hätten wir beide schon gerne benutzt, glaube ich.
Nämlich, dass man diese Enddateien oder halt...
dass man Dateien nach einem bestimmten Pattern zum Beispiel ausblenden kann, dass die in der VM nicht sichtbar sind.
Das geht, glaube ich, mit diesem Governance Feature.
Zumindest lässt die Doku das erahnen.
Und da, wo man die Policies einstellen kann, also die Netzwerk-Policies, da kann man auch Fein-Policies einstellen.
Kann ich aber nicht, weil ich eben das nicht lizenziert.
Also ich vermute mal, wenn man es lizenziert hat, dass man es, dass man dann dort was einstellen kann.
Bei uns steht das nur auf irgendwie Stern, Stern oder sowas und dann allowed.
Da gibt es aber so eine Sektion in diesem Tool.
Also das haben wir jetzt noch gar nicht erwähnt.
Wenn man SBX einfach so aufruft, ohne irgendwelche Parameter, also auch ohne Run oder einfach nur SBX, dann kommt man in so ein TUI, so ein Terminal User Interface.
Das ist wirklich ganz nett gemacht.
Da kann man auch sehr viele Dinge sehen.
Und auch einstellen, der Stefan hatte das vorhin mal oder am Anfang mal erwähnt, dass man dort zum Beispiel, also da kann man sehr komfortabel eigentlich sehen, welche Netzwerkverbindungen zum Beispiel die VM aufmachen wollte und was davon erlaubt oder verboten war und kann dann auch das entsprechend anpassen.
Ich hatte die Netzwerkregeln eher anders verstanden, dass ich sagen kann, bestimmte Leute dürfen bestimmte Pfade überhaupt in eine Sandbox mounten.
Aber wenn das tatsächlich auf Dateisystemmuster geht, ich also sagen kann, bestimmte Dateien werden ausgeschlossen, dann gebe ich dir recht, ist das eines der Feature, die mir fehlen.
Das andere Feature, das mir fehlt, ist feingranularer Netzwerkzugriff.
Also ich kann eben nur auf Host-Ebene erlauben oder verbieten.
Sowas wie raw.githubusercontent.com ist mir eigentlich zu groß.
Weil jeder kann beliebige Inhalte selber auf GitHub veröffentlichen und da würde ich eigentlich...
Lieber sagen wollen, aber nur in bestimmten Verzeichnisbäumen, aber nicht alles, was da ist, sollte der Zugriff erlaubt sein.
Da gibt es durchaus noch Dinge, die mir fehlen.
Es ist nicht so, dass das das rundum sorglos ich bin mit einem glücklich Paket ist.
Also was die Files angeht, das ist vielleicht auch Mutmaßung.
Also ich habe das nur gesehen in diesem User Interface und habe das so interpretiert.
Aber damit wir das auch noch kurz erwähnt haben, für die Files gibt es ja auch ein Workaround.
den wir benutzen.
Man kann nämlich dann anstatt zum Beispiel das Endfile in den Projektordner zu legen, das eine Ebene höher zum Beispiel legen und dann Symbling machen.
Und den Symbling kann, also der funktioniert zwar dann im Host, im normalen System, aber den Symbling kann die VM nicht auflösen, weil die dann nur diesen diesen einen Pfad mounted und dann sieht sie zwar den Simlink, aber das Ziel, wo der Simlink hin zeigt, ist dann halt nicht verfügbar.
Das ist schlau.
Ja, das ist der Workaround jetzt.
Gibt es noch irgendetwas, was wir vergessen haben, aber die Zuhörerinnen auf jeden Fall wissen sollten?
Mir würde im Netzwerkteil noch eine Sache einfallen.
Ich habe das ein oder andere Mal diese Machine in the Middle erwähnt.
Tatsächlich funktioniert die nur für HTTP und HTTPS richtig gut.
Wenn ich andere Netzwerkzugriffe machen möchte, dann widerspricht sich auch so ein bisschen die Doku.
Es gibt Stellen in der Dokumentation, die sagen, außer HTTP und HTTPS geht gar nichts.
Und es gibt andere, die sagen, das geht schon, aber es ist nicht ganz einfach.
Und tatsächlich funktioniert es für TCP-Verbindungen, aber für UDP-Verbindungen scheint es gar nicht machbar zu sein, dass man aus der Sandbox rauskommt.
Wir haben auch Kollegen, die versucht haben, aus der Sandbox heraus, Datenbankzugriffe zu machen, weil sie in der Sandbox Dinge entwickeln wollten, aber auf eine Entwicklungsdatenbankinstanz zugreifen wollten und haben es einfach nicht hinbekommen, diesen Netzwerkzugriff zu erlauben.
Also da kann es dann eben auch sein, dass die Restriktionen für das Netzwerk manchmal so hoch sind oder so kompliziert sind, dass bestimmte Dinge, die man gerne tun möchte, aus der Sandbox-Applaus nicht funktionieren.
Das wäre schon ein Feature, was wichtig wäre.
Also auf eine Datenbank sich verbinden können, wäre schon wichtig.
Okay, gut.
Ja, vielen Dank für das Gespräch.
Ich habe viel gelernt.
Ja, vielen Dank.
Sehr gerne.
Danke dir.
Ciao.
Ciao.
Tschüss.