Docker Sandboxes

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Anja Kammer Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute spreche ich mit Stefan Bodewig und Michael Krämer über Docker Sandboxes. Hallo.

Stefan Bodewig Hallo.

Michael Krämer Hallo.

Anja Kammer 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 eigentlich getroffen? Was ist eine Sandbox überhaupt?

Stefan Bodewig 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 die nicht diese Software verrate, die ich ausführen möchte, ausführen muss, vielleicht aus irgendwelchen Gründen und eher nicht beliebigen Netzwerkzugriff vermitteln möchte, solche Dinge. Also, ich brauche irgendwie ein Gefängnis, eine Quarantänestation für ein Stück Software, dem ich nicht vertraue.

Anja Kammer Mhm. Und ja, welche Schäden können dann angerichtet werden? Also, man macht ja, also, man man 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 was ist das für ein für ein Bedrohungsszenario?

Michael Krämer Na ja, also, man muss das ja so vorstellen, dass jetzt z.B. 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 im Zugriff ist. Ähm, er könnte auch weitere Dinge auf dem Computer installieren, wenn ich z.B. ein dem ja, oder wenn der Agent versucht den Browser zu benutzen, was was ja auch, 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. Ähm und da oder genauso ist es auch mit Schlüsseln, wenn ich jetzt z.B. meinen SSH-Key auf der in meiner Maschine entsperrt habe über über so ein Tool, dass das den, dass nur einmal die Passphrase eingeben muss, dann ist der SSH-Key einfach verfügbar. 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 drauf vertrauen, dass das schon passen wird.

Anja Kammer Mhm, z.B. mit einem extra Key nur für den Agenten z.B..

Michael Krämer Jetzt im Falle von den Keys, genau, oder halt mit einem eigenen Browser oder Browser ähnlichen Tool oder mit eben, also mit irgendeiner Form von Kapselung. Das ist eigentlich das, was man mit der mit der Sandbox dann erreichen möchte.

Anja Kammer Mhm. Ich persönlich habe noch einen anderen Anwendungsfall, also ich persönlich möchte mich z.B. 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?

Stefan Bodewig Grundsätzlich schon. Also, ganz sicher, das sind ja durchaus Bedrohungsszenarien, die 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 irgendwohin zu pushen. Ähm neue Releases von meinen Open Source Projekten zu machen, die eine Hintertür enthalten und sich als Wurm weiter zu verbreiten. 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 ein 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.

Anja Kammer Mhm, okay.

Michael Krämer Wobei man da dazu sagen muss, also eigentlich würde, also ich sehe das zumindest so, dass das wir, dass die Sandbox an der Stelle eigentlich den 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 eine, wie das in manchen Unternehmen ist, so eine Art Content Firewall oder die irgendwelche Fingerprints überprüft, ne? Es gibt ja erstmal einfach Tools, mit denen du eingehende Netzwerkverkehr oder ausgehende Netzwerkverkehr oder auch den Zugriff auf deine Dateien halt irgendwie schützen kannst. Aber ist jetzt nicht so, dass da ein Virenscanner oder irgendwas schon dabei wäre.

Stefan Bodewig Absolut, um auf das erste, was ich gesagt habe, noch mal einzugehen, Software, der ich nicht vertraue, das macht die Software, der 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.

Anja Kammer Mhm. 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?

Michael Krämer Nein, also der das hat jetzt mit Docker oder mit Docker Containern eigentlich nur den Namen gemeinsam. Also, das die Technologie basiert auf einer Micro VM. Also und es hat schon ein bisschen Parallelen mit der mit der Form des Dateisystems, aus dem die Images oder oder mit dem mit dem die VM erstellt wird. Da gibt’s, glaube ich, ein paar Parallelen, aber ansonsten ist es eine Micro VM. Es gibt keinen geteilten Kernel, so wie es bei Docker wäre. Ähm bei Docker habe ich ja jetzt einfach 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 z.B. so einen Agent.

Stefan Bodewig Ähm 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 genauso gegangen, dass ich zwar irgendwo wusste, das ist eine virtuelle Maschine und kein Docker Container, aber trotzdem mir so Containerfragen 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, nee, ist es eben nicht, weil es eine virtuelle Maschine ist, kann ich eben auch Änderungen durchführen und persistieren innerhalb der Maschine.

Anja Kammer Mhm. Michael, du hast gerade gesagt, ein Container ist ja nicht so sicher wie eine virtuelle Maschine. Kannst du das doch mal ausführen, weshalb nicht?

Michael Krämer Ähm also ein Container hat eine geringere Isolation als jetzt eine VM, also die Virtual Machine jetzt erzähle ich hoffentlich keinen Quatsch, also die die Virtual Machine, die Virtualisierung einer Virtual Machine ist ja letzten Endes ein Hardware Feature von von den CPUs, ne, wo man wo man die Möglichkeit hat zu virtualisieren und dann quasi eine auch eine virtuelle CPU, einen virtuellen Computer bereitzustellen und darauf läuft dann ein komplettes Betriebssystem. Und bei Docker ist es 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 anderer Fall und dadurch ist die Isolation einfach noch mal ein Tick höher. Ich glaube aber in der Praxis, das ist jetzt dann zwar noch mal ein anderes Thema, vielleicht kommen wir da eher später noch mal drauf, ist aber so, wenn ich jetzt in einem Container Software entwickle, dann komme ich halt an so 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, so dass es wirklich eine gute Isolation hat. Also, dass ich würde jetzt mal behaupten, also jemand, der einen strengeren Security Fokus hat, der spricht mir da vielleicht, aber ich glaube, normalerweise würde die Isolation von dem Container vielleicht sogar ausreichen, aber der meiner Meinung nach größte Angriffsvektor ist in einem Container dann, wenn ich halt in dem Container noch mal Docker brauche, weil ich dann einfach relativ viel aufmachen muss, damit man aus dem Container wieder auf den Docker Host in irgendeiner Form drauf kommt. Ähm und das brauche ich halt hier nicht und praktischerweise ist bei dem SBX bei Docker Sandboxes sogar ein Docker Host, also quasi in der Micro VM ist ein eigenes Docker installiert, aber komplett getrennt von dem von der von der Hauptmaschine, auf der ich eigentlich arbeite. Und ähm also ich glaube zumindest in der Praxis ist das eigentlich das Haupt Feature, 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.

Stefan Bodewig Ähm tatsächlich, dass die beiden Systeme in einem Container sind ja nicht mal wirklich zwei Systeme, sondern das der Container wie auch das Hostsystem im gleichen Linux Kernel unterwegs sind, hat zusätzliche Angriffsvektoren, die ich nicht mehr habe, wenn ich da eine virtuelle Maschine dazwischen ziehe und wenn ich Bugs im Linux Kernel 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 Michaels Fall, ich weiß, Michael 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.

Anja Kammer Mhm. 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, okay, wie benutze ich das und habe dann euch gefragt, okay, wie benutze ich das und ihr habt dann gesagt, so, 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?

Stefan Bodewig 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 ähm 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. Die hat ja eigentlich genau das getan. Sie hat ihre eigene Lima VM genommen, was ein 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 irgendwohin zugreifen, dann muss ich meine Skript Konfiguration ändern, muss Skript 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 meinen 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.

Anja Kammer Mhm. Und ja, stellen wir uns jetzt mal vor, wir sind in einem Entwicklungsprozess für ein bestimmtes Projekt und ich habe mein Projektverzeichnis mit Code, mit ja, einem Git Repository im Grunde und wie arbeite ich jetzt mit den Dateien? Werden die, also arbeite ich jetzt mit einer Kopie in der virtuellen Maschine und ich muss dann das immer rüber kopieren lassen, damit ich es 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. Also, was habt ihr da so für Erfahrungen gemacht, wie arbeite ich da mit meinen Dateien am besten in der VM?

Michael Krämer Also, eins der Convenience Features, wie 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, Claude oder Codex oder auch noch, was sind noch andere vorbereitet und dann wird on the Fly, wenn es noch keine VM gibt, die zu diesem Verzeichnis gehört, eine angelegt. Ähm und dann werden auch ein paar Dinge einfach schon direkt eingerichtet, also z.B. ähm 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 z.B. jetzt noch einen netter Gimmick, dass der Pfad gleich bleibt. Also jetzt ich arbeite z.B. sonst auf dem Mac, das heißt, mein Home Verzeichnis ist irgendwie /users/michael. 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 z.B. 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 z.B. ein Punkt N 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, ich 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 für GitHub oder GitLab oder was auch immer du benutzt. Ähm und dann gibt es eben dafür Mechanismen, wie man das steuern kann, aber letzten Endes klar, 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 das, dass der das dann eben auch macht oder machen kann, zumindest.

Stefan Bodewig Ähm 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 deinem 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 funktionieren. Damit habe ich allerdings selber null Erfahrung. Ich habe das nie benutzt. Es gab auch vor ein paar Monaten mal das Feature, dass verschiedene Sandboxes Git Worktrees benutzt haben, aber das ist so ein bisschen, was wir reden über 0.3 irgendwas Versionen 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. Was ich nicht, Michael, hast du das mal benutzt? Ich habe das noch nie eingesetzt.

Michael Krämer Nein, habe ich bisher nicht. Ähm also da wurde ich auch schon mal bei einem Vortrag nachgefragt, aber also du hast schon recht, ne, es ist der Standardmodus, aber ich muss sagen, also für mich persönlich, ähm 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. Ähm ne, deshalb z.B. was eben gesagt haben mit diesem, 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, dass mir selber jetzt so zu konfigurieren, also auch auf deine Frage hin mit dem, könnte ich mir nicht mit KVM oder mit mit irgendwas das selbst bauen? Ähm hat ja Stefan schon gesagt, klar, könnte man, aber wahrscheinlich hätte ich auch nicht unbedingt all diese Entscheidungen so getroffen und ich finde sie super praktisch, wie also die meisten, so wie sie sind. Ja, also das mit diese diesen anderen Modus habe ich noch nicht benutzt, ne.

Stefan Bodewig 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.

Anja Kammer Ja. Das klingt so, als wäre Docker Sandboxes irgendwie noch ein frisches und neues Tool und noch gar nicht so stabil.

Stefan Bodewig Das Kern Feature Set ist schon stabil. Es gab eben solche Dinge wie den Worktree Models, der in also 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 Features 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, dass 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 lesen Zugriff, lesende Zugriffe erlauben und ich kann Schreibzugriff auf diesen Verzeichnissen haben. Das ist was, 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 noch mal ändern von den Dingen, die man sieht.

Michael Krämer Ähm ich bin mir da nicht hundertprozentig sicher, aber ich glaube, also, äh ich glaube Docker Sandbox ist jetzt nicht mehr Early Access, also das Tool an für sich, sondern ähm ich meine, das sei jetzt einfach so offiziell. Es gibt Features, die sind Early Access. Ähm aber also, als wir angefangen haben, das zu benutzen, ähm da war es äh tatsächlich oder war das ganze Tool in dem Status. Und ähm ähm genau, was halt passiert ist, also, wenn du sagst stabil, ähm da muss man überlegen, was man mit stabil meint. Also, ich finde es, also, es ist jetzt mir noch nie gecrasht, ne? Also, das es ist schon voll okay vom von der Stabilität zur Laufzeit sozusagen, aber es ändert halt viel. Also, es ist relativ volatil, äh 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, ähm das das Flag war einfach nicht da. Ähm und das also geht halt vieles relativ schnell, ähm da, aber wenn man dann irgendwie ein paar Tage wartet, dann ähm hat sich das dann auch eingependelt.

Anja Kammer Mhm. 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 und ja, warum warum es mich so äh ja, also, warum es so toll ist vor allem?

Stefan Bodewig Also, ähm um die virtuelle Maschine, die in dieser Docker Sandbox drum rum läuft, wird mit Betriebssystemmitteln das Netzwerk abgedichtet. Also, ich habe im Wesentlichen habe ich einen Proxy, der zwischen der 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 ähm 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’s 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 innen aus der Sandbox ein Netzwerkzugriff nicht geklappt hat, irgendwas nicht funktioniert, kann ich außen ähm 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’s einfach noch mal innerhalb dieser Sandbox und dann kommt’s eben normalfall auch raus und das funktioniert, ohne dass ich irgendwas groß neu starten muss. Für mich habe ich ein paar Dinge tatsächlich, ich 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, 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 na ja, 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.

Michael Krämer Machst du das wirklich so, dass du dann nur für die Sandboxes, wo du Claude Code benutzt, die Anthropic API freigibst?

Stefan Bodewig Ja. Aber das ist ein Kit. Also, es ist ein wir kommen irgendwann später dazu, was Kits sind, aber du kannst den Kits sagen, wo worauf du Zugriff äh geben möchtest und bei den Sandboxes, wo ich Claude Code benutzen möchte, binde ich ein Kit ein, dass die richtigen Netzwerkzugriffe erlaubt.

Anja Kammer Wenn du schon Kits sagst,

Stefan Bodewig auf diesem gut ist ein bisschen dicker als bei anderen Leuten.

Anja Kammer Wenn du schon Kits sagst, warum also, warum reden wir nicht jetzt schon über Kits? Also, sind das sowas wie Plugins?

Michael Krämer Also, es ich würde sagen, das sind so ergänzt, also, du kannst halt über ein Kit erreichen, dass bestimmte Dinge quasi zu, also, du musst jetzt kein eigenes Image bauen, ne, das wäre ja der das könntest du auch tun, glaube ich, habe ich auch noch nie gemacht. Ähm aber ähm du könntest ja jetzt auch sagen, nee, so wie äh das Image jetzt irgendwie von von Docker quasi vorgeschlagen wird, so passt mir das nicht, aber mit den Kits ist halt deutlich einfacher, weil du kannst bei dem Standard Image bleiben und kannst dann halt additiv irgendwelche Dinge über so ein Kit ähm hinzufügen. Und ähm und damit ähm dann z.B. so wie Stefan das gerade gesagt hat, mit den Netzwerkzugriffen, aber das könnte auch sein, dass du jetzt z.B. Skills äh für den Agent ähm hinzufügen möchtest und das äh kannst du dann ähm eben über äh ein über ein Kit könnte könntest du das machen, dass du dein Default Skillset da irgendwie mit rein nimmst.

Stefan Bodewig 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 Sandboxes, 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 mich überall ein Open JDK in einer bestimmten Version in der Sandbox habe, mache ich das nicht global, sondern eben für jede Sandbox einzeln einmal. Das ist das ist ja ein Debian basiertes System, sind es einfach im Wesentlichen zwei APT Kommandos, die man in das Kit reinschreibt, um die richtigen vielleicht sind 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 Netzwerkzugriffe regeln, du könntest Secrets hinterlegen, noch mal ein anderes Thema. Ähm da gibt’s 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’s dann vordefinierte Agents für die meisten großen ähm Agentic Coding Umgebung, die in der Shell laufen, also Claude 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 ein Skills Contrib Repository, wo Leute ihre Skills zur Verfügung stellen als Open Source Projekte und darin findet sich z.B. was für pi.dev, 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, der 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.

Anja Kammer Ja, ich ich ich hatte äh gar nicht dran 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 äh Dinge nachinstallieren und aufrufen und so weiter. Das klingt jetzt eher danach, als wäre das sehr abgeschottet und als bräuchte man Kits, um Dinge nachzuinstallieren. Äh ist das korrekt? Habe ich das falsch verstanden?

Michael Krämer Nee, brauchst du nicht. Also, du könntest dich auch einfach ähm also ähnlich wie bei Docker, also jetzt nicht die Firma Docker, sondern das Tool, kannst du halt auch mit Exec z.B., also SBX Run ist das, womit du eigentlich normalerweise eine äh eine von diesen VMs startest und dann wird eben diese wie 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. Ähm da hängt aber dann auch noch dran, dass das Base Image verschieden ist. Also, wenn ähm wenn du jetzt SBX Run Claude aufrufst, dann nimmt er ein anderes Base Image wie, also, dann nimmt er halt eins, wo Claude installiert ist, wenn du SBX Run Copilot 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. Ähm und eben Shell ist dann auch wieder ein anderes Image, das vielleicht wahrscheinlich gar kein Agent äh sonst installiert. Aber du kannst natürlich mit SBX Exec z.B. in eine bestehende VM ähm dich einfach wie einloggen und hast dann dort ein Terminal. Ähm und ähm dann kannst du auch dort einfach apt-get, was auch immer tun und das meinte ja Stefan mit äh ganz am Anfang, es ist einfach eine VM, also, die hat einen State. Die hat eine die hat eine Disk oder ein Disk Image. Ähm und äh 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 ähm in der VM äh nachinstallierst, dann sind die zwar dort, ähm aber äh die bleiben dann halt so, wie sie sind. Also, das Thema mit den Updates, da können wir vielleicht gleich noch mal drüber reden, das finde ich nämlich spannend, wie Stefan das macht. Ähm aber ähm ä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, ähm 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 ähm die halt in irgendeiner Form weiterentwickle. Und dann, wenn ich jetzt äh also, ich habe sehr viele von diesen VMs, ähm weil ich das normalerweise, also, weil ich an vielen Projekten parallel arbeite und dann typischerweise für jedes Projekt eine eigene VM hab und dann ist es sehr schwierig, den das nachzuhalten, wo jetzt welche Version von was hinkopiert wurde und diese Kits, wenn man halt ähm die Kits äh einbindet, dann kann man das auch erreichen, dass er quasi das beim Starten immer wieder rüber kopiert.

Anja Kammer Ah, okay, verstanden. Danke schön.

Stefan Bodewig Genau, und du kannst natürlich Software installieren ohne ein Kit, dass ich sowas wie das .NET SDK mit einem Kit installiere, ist einfach, damit ich das nicht sieben Mal machen muss, damit ich nicht sieben Mal 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 ist mir im Gespräch mit einem Kollegen äh kam das auf, dass er sagte, das Nette daran ist, dass die composable sind, dass sie sich 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, weil sowas wie Sandboxes kann ich aber die drei Kits, die Rust und Node und was ich nicht was, war das andere, was ich gesagt habe, Python installieren mit den passenden Modulen, kann ich eben die drei Kits einfach zusammenfassen und dann habe ich die Dinge miteinander komponiert. Sind wirklich eigenständiger und damit auch leichter als Bausteine zu nutzen, als das Layer wären, die ich bei einem Docker Container oben drauf lege.

Anja Kammer Ja, Michael, du wolltest doch jetzt Stefan fragen.

Michael Krämer Ja, ähm genau, also, wie äh wie machst du das denn mit den Updates, weil ich habe halt das Gefühl, wenn ich, also, vielleicht liegt’s auch daran, dass ich so viele VMs habe, ähm aber 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.

Stefan Bodewig 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 managest du eigentlich deinen Festplattenplatz, weil Micro VM klingt viel kleiner, als es am Ende tatsächlich ist. Das 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 jetzt gerade etwas weniger VMs, als ich vorher gehabt habe und natürlich habe ich noch andere Dinge geändert, damit es zukünftig nicht mehr passiert, hoffe ich zumindest, aber ähm wie machst du das bei ganz ganz vielen VMs mit dem Festplattenplatz, weil das, was mir gerade fehlt, ist ein räum mal alte Snapshots weg Feature tatsächlich. Ich glaube, das gibt’s in der Form nicht. Ich habe den Eindruck, die belegen viel viel mehr Plattenplatz, als sie bräuchten.

Michael Krämer Also, ähm ja, also, mal der Reihe nach, also, ich ähm ich müsste jetzt nachschauen, ich denke, ich habe, also, ich habe auch hier neulich aufgeräumt, äh weil auch meine Disk voll gelaufen ist, aber ich glaube, es lag an was anderem, ähm und nicht nur an den VMs und ich hatte aber zuerst die VMs im Verdacht, ähm weil er auch angezeigt hat, irgendwie, ich hätte 980 GB VMs oder sowas hat mein Finder angezeigt. Äh es scheint aber so zu sein, ich ich musste dann einfach aufräumen und hatte keine Zeit für Forensik, ähm aber es scheint so zu sein, dass diese Angabe falsch war. Also, ähm ich hatte wahrscheinlich keine 980 GB VMs, sondern da waren einige vielleicht, ich weiß nicht, ob der Hardlinks benutzt, äh oder was er da macht. Jedenfalls, ich glaube, diese Angabe war falsch, aber du hast total recht, ähm eine VM belegt relevant Festplattenplatz. Ähm ich denke, Micro bezieht sich auch eher auf den sozusagen Footprint zur Laufzeit und weniger auf den Disk Space. Ähm Absolut. Und ähm also, ich habe jetzt äh ich habe diese Gelegenheit genutzt und auch mal VMs weggeworfen, die ich gar nicht mehr benutze, äh oder die ich lange nicht mehr benutzt habe und letzten Endes, wenn man z.B. diese Kits anlegt, ähm dann ist es, dann sind die VMs im Prinzip auch reproduzierbar. Also, wenn ich die später wieder starte in dem gleichen Ordner und z.B. dann ein Kit angebe oder vielleicht auch nicht, wenn mir der Default reicht, dann ähm kriege ich schon etwas anderes, wie das, was ich vorher hatte. Also, es ist ja so, dass durch die Updates von Docker Sandbox ähm und 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, ein neueres Base 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 hab, ähm da ja, also, ich komme damit zurecht mit dem bisher mit dem Disk Space, ähm 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, ich wenn ich sie halt wegschmeiße und sie neu anlege, dann weiß ich, ah, dass ich darin quasi keinen Shadow State, also, nicht irgendwelche Dinge hab, 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 in irgendwelchen Dingen hab, wo ich auch ein Backup von hab und nicht nur auf meiner lokalen Disk. Ähm und Updates mache ich schon, aber äh Aber ich finde das 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 Kits zu erstellen, da wo ich Anpassungen brauche. Wenn ich das nicht sowieso schon gemacht habe.

Stefan Bodewig Hört sich richtig an, sollte ich auch tun.

Anja Kammer Mhm.

Stefan Bodewig 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 tippst da drin SBX Run und den Agent, den du haben möchtest, vielleicht noch ein paar andere Kommandozeilenparameter und dann startet halt der Agent in deinem Terminal. Das heißt, es ist das Kommandozeileninterface deines Agents, das in deinem Terminal läuft. Das ist 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 was ich nicht, das die Desktop-Anwendung von Claude 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 der neuesten Version 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 Daemon 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.

Anja Kammer Ich gehe davon aus, dass es auch keine wirklichen Integrationen für IDEs gibt, oder? Also, man weiß ja, dass IDEs so ihre eigenen Chatprogramme haben und worin sie dann beispielsweise Claude oder oder ChatGPT und so weiter zur Verfügung stellen. Das bedeutet, auch diese Graphical User Interfaces in meiner IDE kann ich nicht unbedingt mit Docker Sandboxes verbinden, oder?

Michael Krämer Doch, kannst du schon. Ähm, also je nachdem, was du für eine IDE nutzt. Ähm, aber jetzt, also ich benutze das nicht mehr wirklich. Ich habe schon, also ich mache viel Java, ich habe aber schon eine Weile mal in IntelliJ, oder ich benutze es wirklich nicht mehr so häufig, weil einfach der Agent viel macht. Ähm, aber wenn ich ähm, du kannst halt viel machen auch über einen MCP Server, ne? Also z.B. die IDEs stellen jetzt häufig MCP Server zur Verfügung, worüber dann ähm du eine Integration hinbekommst. Aber die das, was Docker Sandbox an Integration nennt, das ähm gibt es, glaube ich, nur für VS Code und für Cursor oder sowas. Aber auch das habe ich noch nie benutzt.

Anja Kammer Aber das ist ja schon ein Anfang.

Stefan Bodewig 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 Shellfenster. Und dann führt es da eben aus. 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 Michael, dass 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 Features der IDE genutzt hat und das was jetzt noch übrig ist, kann ich auch genauso gut in Emacs machen.

Anja Kammer Das stimmt, ja.

Michael Krämer Da ist es halt ähm praktisch, also, wenn man jetzt z.B. das Terminal in der IDE benutzt, um in dem Terminal SBX mit einem Agent zu starten, ähm 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 pasen 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, ähm kann ich da im Prinzip drauf klicken 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, ähm, also ich gehe davon aus, das hat aber eigentlich auch nichts mit SBX zu tun, sondern eher insgesamt mit den Agents, ähm sowas wie ein Refactoring oder das Umbenennen von von irgendeiner ähm von von irgendeinem Namen in einer kompilierten und typisierten Sprache. Das war über die Agents ja immer ziemlich mühsam, weil die dann die kennen, also die haben ja keinen Linter, die haben keinen kein kein Syntax Tree normalerweise, sondern machen das halt alles Textbasiert. Und das geht jetzt z.B. zum Teil über MCP Server, die die IDE zur Verfügung stellt. Also das das das hat aber eigentlich auch eben nichts mit SBX zu tun, ne? Das das würde auch mit dem mit dem Agent einfach so gehen, wenn der hier im Terminal läuft und neben dran ist die IDE und das kann ich aber in SBX mehr oder weniger genauso machen.

Anja Kammer Mhm. Lass uns doch einmal Links zu diesen Projekten in den Shownotes zusammenfassen. Ich denke, das ist für alle interessant. Für mich zumindest.

Michael Krämer Ja, gerne.

Anja Kammer Ja, das klingt auch schon gut. Ähm, 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. Ähm, wie genau funktioniert das? Also so Header Manipulation, oder? Wie war das?

Stefan Bodewig Genau, also der Proxy, von dem ich eben gesprochen habe, ist zumindest ist für eigentlich alles ist es ein Machine in the Middle Proxy. Das heißt, ähm 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 und Zweifel sich selber als Trusted Certificate Authority eingetragen, so dass 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 äh wenn er in bestimmten HTTP Headern Platzhalter findet, 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 Variablen in der Sandbox erzeugt. Da steht dann aber replaced by Proxy oder sowas drin, aber du sagst halt, ähm deinem 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 meine Basic Auth oder Token basierte Authentifizierung drin stecken 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 OAUTH2 beispielsweise angehen, kann dieser Proxy eben auch die Redirect URI für OAUTH2 anbieten. Also, um das um jetzt nicht zu technisch zu werden, im Wesentlichen fängt der Proxy das ausgestellte Token bei einem OAUTH2 Flow ab und kennt dann das Token aber nicht innen drin. Das heißt, wenn ich für Anthropic geht es irgendwie schon sehr sehr lange, wenn ich in Claude ein /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 der 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 drü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 Quelltext ich auch nicht einsehen kann.

Anja Kammer Ah, es ist also kein Open Source Projekt?

Stefan Bodewig Es setzt sich aus einigen Open Source Komponenten zusammen, aber das komplette Ding ist nicht wirklich Open Source. Das was bei GitHub ist, ist das ist 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 ist eine Kombination 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.

Anja Kammer Könnte es so aussehen, dass es irgendwann hinter einer Bezahlschranke verschwinden wird, dieses Tool? Was, was denkt ihr?

Michael Krämer Das hatten wir am Anfang ja so ein bisschen befürchtet, als das Ganze noch Early Access war, ähm und eben, also ist kein Open Source, ähm 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, äh aber man muss auch regelmäßig, ähm wenn man SBX äh aufruft auf der Kommandozeile, dann ähm passiert es immer wieder, dass man äh quasi das auch so wie wie ähm Stefan das gerade beschrieben hat von dem Anthropic Login, dass dann quasi aus der Kommandozeile raus ein Browser aufgeht, äh und man dort eine Bestätigung oder da muss man eingeloggt sein bei Docker mit dem Browser und dann muss man dort äh das freigeben. Ähm, also die das Tool selbst kann man wirklich nicht benutzen, ohne dass man zumindest preisgibt, wer man ist. Ähm und das äh jetzt auch bei uns von alle bei einigen Kollegen ist es nicht so wirklich gut angekommen. Ja. Ähm kann ich auch, ja, erstmal nachvollziehen, also richtig offen wäre natürlich besser. Aber ich glaube, dass die Standard Features, über die wir jetzt gesprochen haben, ähm alle frei bleiben, zumindest war das die letzte Kommunikation, äh auch für kommerziellen Einsatz und was die halt verkaufen wollen, ist so, wie nennen sie das? Ähm, also so ein Enterprise Feature haben sie quasi, wo man, wo man erreichen könnte, dass ähm dass man zentral irgendwo was konfiguriert, wie auf den auf den Arbeitsplatzrechnern halt die Sandboxes irgendwie z.B. bezüglich Netzwerk Policies konfiguriert werden oder sowas.

Anja Kammer Mhm.

Stefan Bodewig 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. Ähm, ich glaube, es gibt auch noch so Dinge wie Teamweite ähm 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 gäbe 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 Features von äh Docker Sandboxes nutzt. Das sind aber alles Dinge, die mich überhaupt nicht interessiert haben, deshalb habe ich auch überhaupt nicht angeguckt, was da mit im Detail nachher funktioniert oder nicht funktioniert.

Michael Krämer Ja, genau, Governance, das war das Wort, was ich eben gesucht habe. Aber ähm, also ein Feature gibt es, was scheinbar da drin steckt, äh und das hätten wir beide schon gerne benutzt, glaube ich, nämlich, dass man diese Elf Dateien oder halt, dass man Dateien nach einem nach einem bestimmten Pattern z.B. ausblenden kann, dass die in der VM nicht sichtbar sind. Das geht, glaube ich, mit diesem Governance Feature. Äh zumindest lässt die Doku das erahnen und da wo man die Policies einstellen kann, also die Netzwerk Policies, da kann man auch File Policies einstellen. Ähm 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 erlaubt. Da gibt’s aber so eine Sektion in diesem äh in dem in dem Tool. Also, das haben wir jetzt auch gar nicht erwähnt, wenn man SBX einfach so aufruft, ohne ohne irgendwelche Parameter, also auch ohne Run oder einfach nur SBX, dann kommt man in so ein TUI, so ein so ein Terminal User Interface, das ist wirklich ganz nett gemacht. Da kann man auch sehr viele Dinge sehen und und auch einstellen. Der Stefan hatte das vorhin mal oder am Anfang mal erwähnt, dass man dort z.B., also da kann man sehr komfortabel eigentlich sehen, welche Netzwerkverbindungen z.B. der die VM aufmachen wollte und was davon erlaubt oder verboten war und kann dann auch das entsprechend anpassen.

Stefan Bodewig Ich hatte die Netzwerkregeln eher anders verstanden, dass ich sagen kann, bestimmte Leute dürfen bestimmte Pfade überhaupt in einen 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 Features, die mir fehlen. Das andere Feature, das mir fehlt ist feingranularerer Netzwerkzugriff. Ich kann eben nur auf Hostebene erlauben oder verbieten. Sowas wie raw.githubusercontent.com ist mir eigentlich zu groß. Ähm, weil jeder kann beliebige Inhalte selber auf GitHub veröffentlichen und äh 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’s durchaus noch Dinge, die mir fehlen. Das ist nicht so, dass das das rundum sorglos, ich bin mit allem glücklich Paket ist.

Michael Krämer Also, was die Files angeht, ähm das ist vielleicht auch Mutmaßung, ne? Also, ich ich habe es nur gesehen in diesem User Interface und habe das so interpretiert. Ja. Aber damit wir das auch noch kurz erwähnt haben, für die Files gibt’s ja auch ein Workaround, den wir benutzen. Man kann nämlich ähm dann anstatt z.B. das Endfile in den Projektordner zu legen, das eine Ebene höher z.B. legen. Ja. Und dann Symlink machen. Mhm. Und den Symlink kann, also der funktioniert zwar dann im Host, im im normalen System, aber den Symlink kann ähm Docker, also kann die VM nicht auflösen, weil die dann nur diesen ähm diesen einen Pfad mountet und dann sieht die zwar den Symlink, aber das Ziel, wo der Symlink hin zeigt, ist dann halt ähm nicht verfügbar.

Anja Kammer Mhm, das ist schlau.

Michael Krämer Ja, ist der Workaround jetzt.

Anja Kammer Gibt es noch irgendetwas, was wir vergessen haben, aber die Zuhörerinnen auf jeden Fall wissen sollten?

Stefan Bodewig 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. Ähm, wenn ich andere Netzwerkzugriffe machen möchte, dann widerspricht sich auch so ein bisschen die Doku. Ähm, 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 Verbindung, aber für UDP Verbindung 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 Entwicklungsdatenbank Instanz 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 heraus nicht funktionieren.

Anja Kammer Ja, das wäre schon ein Feature, was wichtig wäre, ne? Also auf eine Datenbank sich verbinden können, wäre schon wichtig, ja. Okay, gut. Ja, vielen Dank für das Gespräch. Ich habe viel gelernt. Ähm, ja, vielen Dank.

Stefan Bodewig Sehr gerne.

Michael Krämer Danke dir.

Anja Kammer Ciao.

Stefan Bodewig Ciao.

Michael Krämer Tschüss.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Wozu Docker Sandboxes: Das Gefängnis für nicht vertrauenswürdige Software

Stefan Bodewig erklärt die Grundidee: Software ausführen, der man nicht vollständig vertraut, ohne dass sie Schaden anrichten kann. Michael Krämer konkretisiert das Bedrohungsszenario am Beispiel von KI-Agenten, die lokal gestartet automatisch alle Rechte des Nutzers erben – Dateizugriff auf der gesamten Platte, Browser-Cookies, entsperrte SSH-Keys.

„Ich brauche irgendwie ein Gefängnis, eine Quarantänestation für ein Stück Software, dem ich nicht vertraue.“

Welche Berechtigungen hätte ein KI-Agent bei Ihnen aktuell, wenn Sie ihn einfach lokal starten würden?

Micro VM statt Container: Warum die Isolation stärker ist

Anja Kammer fragt nach dem Unterschied zu klassischen Docker-Containern. Michael Krämer erklärt, dass Docker Sandboxes trotz des Namens auf einer Micro-VM basieren statt auf einem geteilten Kernel. Stefan Bodewig ergänzt, dass dadurch ganze Klassen von Angriffsvektoren – Kernel-Bugs, Fehler im Namespacing – wegfallen.

„Das hat jetzt mit Docker oder mit Docker Containern eigentlich nur den Namen gemeinsam.“

Wie schätzen Sie das Risiko ein, KI-Agenten aktuell in einfachen Containern statt in einer eigenen VM laufen zu lassen?

Convenience statt Marke Eigenbau

Anja Kammer hatte sich zuvor selbst eine KVM-VM gebaut. Stefan Bodewig macht klar, dass Docker Sandboxes technisch kaum etwas kann, was man nicht auch selbst bauen könnte – der eigentliche Mehrwert liegt in der Convenience: Netzwerk-Policies, Proxy und Setup kommen fertig, statt sie mühsam selbst zusammenzuschrauben.

„Das, was du bekommst, ist in erster Linie mal Convenience.“

Wägen Sie in Ihren Projekten eher Marke Eigenbau oder fertige Tools ab, wenn es um Sicherheitsmechanismen geht?

Kits: Composable Bausteine statt Container-Layer

Zentrales Konzept sind „Kits" – wiederverwendbare Bausteine, die Netzwerkzugriffe, Software-Installationen, Dateien oder sogar eigene Agent-Definitionen in eine Sandbox einbringen. Der Clou laut Stefan Bodewig: Kits lassen sich beliebig kombinieren, während bei klassischen Container-Images übereinandergelegte Layer schnell in Konflikte geraten.

„Sind wirklich eigenständiger und damit auch leichter als Bausteine zu nutzen, als das Layer wären, die ich bei einem Docker Container oben drauf lege.“

Welche wiederkehrenden Setup-Schritte in Ihren Projekten ließen sich als solche wiederverwendbaren Bausteine bündeln?

Secrets, die der Agent nie zu Gesicht bekommt

Ein zentrales Sicherheitsfeature ist der Machine-in-the-Middle-Proxy: Er bricht HTTPS auf und ersetzt Platzhalter in HTTP-Headern durch echte Secrets, bevor die Anfrage die Sandbox verlässt. Selbst bei OAuth2-Logins bleibt das echte Token im Proxy, nicht im Agent. Die Kehrseite: Man muss diesem Mechanismus von Docker Inc. vertrauen, dessen Quelltext nicht öffentlich einsehbar ist.

„Ich muss nicht mehr dem Code, der in der Sandbox liegt, vertrauen. Dafür muss ich jetzt Docker Incorporated vertrauen.“

Wie viel Vertrauen sind Sie bereit, einem Tool-Anbieter für sicherheitskritische Mechanismen wie Secret-Handling entgegenzubringen?