E2B Workload Identity lässt Backends prüfen, welche Sandbox anfragt

Das Problem: Ein gemeinsamer Schlüssel verrät nicht, wer anfragt

Wenn eine Sandbox ein Dokument abruft, das Ergebnis einer Aufgabe übermittelt oder einen internen Dienst aufruft, muss das empfangende Backend wissen, wer die Anfrage stellt und was dieser Aufrufer tun darf. E2B weist darauf hin, dass ein gemeinsamer API-Schlüssel eine Anfrage authentifizieren kann, aber nicht erkennen lässt, welche Sandbox sie gesendet hat.

Die Alternative besteht darin, für jede Sandbox ein eigenes Zugangstoken auszustellen. Dafür muss jedoch eine Infrastruktur zur Verteilung, Rotation und Nachverfolgung dieser Zugangsdaten aufgebaut werden. E2B zufolge soll Workload Identity diesen Prozess vereinfachen. Das Unternehmen bezeichnet die Funktion als weiteren Schritt, um Sandboxes für echte Anwendungen nutzbar zu machen: Agenten benötigen Zugriff auf die Systeme von Kunden, und diese Systeme brauchen eine zuverlässige Möglichkeit, sie zu identifizieren.

So funktioniert die Funktion

Beim Erstellen einer Sandbox legt ein Entwickler ein benanntes Workload-Token und dessen Zielgruppe fest, also den Dienst, der es empfangen soll. Anschließend wird dieses Token in einer Netzwerkregel referenziert. Verlässt eine passende HTTPS-Anfrage die Sandbox, fügt E2B dem vom Entwickler konfigurierten Anfrage-Header ein signiertes Token hinzu.

E2B stellt das Token außerhalb der Sandbox aus. Dadurch bleibt es aus der Umgebung und dem Dateisystem der Sandbox heraus. Das Token enthält ein Ablaufdatum und die vorgesehene Zielgruppe. Im Beispiel der Ankündigung wird das Token mit dem E2B SDK über Secret.iamToken definiert, mit api.example.com als Zielgruppe und dem Tokentyp JWT-SVID.

• Die Referenz iam.tokens.backend ist ein Platzhalter, nicht das JWT selbst. E2B ersetzt sie beim Weiterleiten passender Anfragen durch das echte Token.
• E2B kann ein zwischengespeichertes Token für dieselbe Sandbox-Ausführung und Zielgruppe wiederverwenden, solange es gültig ist.
• Jeder HTTP-Anfrage-Header, den der Dienst erwartet, kann verwendet werden.
• Der Code innerhalb der Sandbox stellt eine normale HTTPS-Anfrage, etwa mit curl, und muss keinen Authorization-Header senden, auch nicht mit einem Dummy-Wert.

Verwendet ein HTTP-Client sein eigenes CA-Bundle, muss er so konfiguriert werden, dass er E2Bs Egress-Proxy vertraut. E2B verweist Entwickler auf seine Dokumentation zu TLS-Zertifikaten für Python Requests und Node.js.

Identität prüfen und Berechtigungen festlegen

Für E2B Cloud veröffentlicht das Unternehmen ein OpenID-Connect-(OIDC-)Discovery-Dokument. Darin wird https://id.e2b.dev als Aussteller genannt und auf das JSON Web Key Set (JWKS) mit den öffentlichen Signaturschlüsseln von E2B verwiesen. BYOC-Bereitstellungen verwenden ihre eigene Aussteller-URL und öffentliche Schlüssel. Diese werden konfiguriert, wenn der Support Workload Identity für die Bereitstellung aktiviert.

Ein Backend kann eine JWT-Bibliothek zur Verifizierung verwenden, um die Schlüssel abzurufen und zwischenzuspeichern. E2B empfiehlt, sie so zu konfigurieren, dass sie ES256-Signaturen akzeptiert, den erwarteten Aussteller und die erwartete Zielgruppe verlangt und die Ablauf- sowie die Not-Before-Zeit prüft. Außerdem sollte das Backend bestätigen, dass der Betreff des Tokens zum erwarteten Projekt und zur erwarteten Sandbox-Ausführung gehört.

Die Zugriffsregeln bleiben beim Kunden. Ein Backend, das beispielsweise eine Dokumentverarbeitungsaufgabe startet, kann die Sandbox-ID mit dieser Aufgabe verknüpfen und die Zuordnung vor der Rückgabe von Daten prüfen. Auf dieselbe Weise kann eine Sandbox Ergebnisse für ihren zugewiesenen Auftrag übermitteln oder ein bestimmtes internes Tool aufrufen. In den Worten von E2B stellt das Unternehmen die signierte Workload-Identität bereit, während der Kunde entscheidet, auf welche Ressourcen und Vorgänge sie zugreifen darf.

Beispiel: Temporäre AWS-Zugangsdaten

Die Ankündigung beschreibt außerdem ein AWS-Szenario, in dem eine Sandbox ein Objekt aus einem S3-Bucket lesen muss. Das Backend empfängt das eingefügte E2B-JWT, tauscht es beim AWS Security Token Service (STS) ein und verwendet die daraus resultierenden temporären Zugangsdaten, um das Dokument abzurufen. Dafür wird die Zielgruppe des Tokens auf sts.amazonaws.com gesetzt.

• E2B wird einmal pro Aussteller und Konto als OIDC-Anbieter in dem AWS-Konto registriert, dem die Rolle gehört.
• Eine Vertrauensrichtlinie für die Rolle beschränkt den Zugriff anhand der Zielgruppe und eines an die E2B-Projekt-ID gebundenen Betreffmusters. E2B weist darauf hin, dass die Registrierung des Anbieters allein den Zugriff nicht auf ein Projekt beschränkt.
• Die Rolle erhält Zugriff auf ein einzelnes S3-Objekt.
• Eine Flask-App mit boto3 liest das Bearer-Token, ruft damit STS auf und gibt nur das Dokument an die Sandbox zurück.

Im Beispiel laufen die AWS-Zugangsdaten nach 15 Minuten ab, unabhängig vom E2B-Token. Langfristige AWS-Zugangsschlüssel werden nicht benötigt. E2B warnt, dass in diesem Beispiel jede von der Vertrauensrichtlinie akzeptierte Identität dasselbe Dokument lesen kann. Bei Dokumenten, die einzelnen Sandbox-Aufgaben zugeordnet sind, sollte die verifizierte Identität zusätzlich mit den Berechtigungen dieser Aufgabe abgeglichen werden. Bei BYOC können sich der Host des Ausstellers und die konfigurierte Vertrauensdomäne im spiffe://-Betreff unterscheiden. Der Support kann beide Werte bereitstellen.

Was das für Entwickler bedeutet

Für Teams, die Agenten in E2B-Sandboxes ausführen, bietet die Funktion eine Möglichkeit, jede Sandbox gegenüber den eigenen Diensten zu identifizieren, ohne Geheimnisse pro Sandbox auszugeben und zu verwalten. Da das Token außerhalb der Sandbox hinzugefügt wird, gelangt es nie in den Code innerhalb der Sandbox. Workload Identity ist auf E2B Cloud allgemein verfügbar. BYOC-Nutzer müssen den Support bitten, die Funktion für ihre Bereitstellung zu aktivieren.