Az E2B azonosíthatóvá teszi a sandboxokból érkező kéréseket

A közös API-kulcs nem azonosítja a sandboxot

Az E2B szerint egy sandboxnak gyakran kell dokumentumot lekérnie a háttérrendszerből, egy feladat eredményét elküldenie vagy belső szolgáltatást meghívnia. Ilyenkor a háttérszolgáltatásnak tudnia kell, ki küldte a kérést, és milyen műveleteket engedélyezhet számára.

Egy közös API-kulcs hitelesítheti a kérést, de nem mutatja meg, melyik sandbox küldte azt. Külön hitelesítő adat létrehozása minden sandboxhoz megoldhatja az azonosítást, ugyanakkor gondoskodni kellene ezek terjesztéséről, cseréjéről és nyomon követéséről. Az E2B Workload Identity ezt a folyamatot kezeli.

Az E2B a projektre, a sandboxra és a végrehajtásra vonatkozó azonosítót tartalmazó, aláírt JWT-t biztosít. A szolgáltatás ellenőrizheti az aláírást és az állításokat, majd a saját hozzáférési szabályai alapján dönthet.

A token a sandboxon kívül kerül a kérésbe

A sandbox létrehozásakor a fejlesztő megadja a munkaterhelési token nevét és célközönségét, vagyis azt a szolgáltatást, amelynek a token szól. Ezután a tokent egy hálózati szabályhoz kapcsolja. Amikor a sandboxból illeszkedő HTTPS-kérés indul, az E2B a beállított fejlécben hozzáadja az aláírt tokent.

A token kiadása a sandboxon kívül történik, így a hitelesítő adat nem kerül be a sandbox környezetébe vagy fájlrendszerébe. A token lejárati időt és célközönséget tartalmaz. A háttérszolgáltatásnak az aláírás mellett ezeket az adatokat, a kibocsátót és a hívó identitását is ellenőriznie kell.

A sandboxban futó kód közben normál HTTPS-kérést indít, például a curl --fail https://api.example.com/data paranccsal. Az Authorization fejlécet nem a sandboxnak kell elkészítenie, azt az E2B egress proxyja illeszti be a kérés továbbításakor. A szolgáltatás által elvárt HTTP-fejléc szabadon kiválasztható.

A hozzáférési szabályokat a háttérrendszer határozza meg

Az E2B Cloud OpenID Connect felfedezési dokumentumot tesz közzé. Ez az https://id.e2b.dev címet jelöli meg kibocsátóként, és a JSON Web Key Setre, vagyis az E2B nyilvános aláírókulcsaira mutat. A háttérrendszer JWT-ellenőrző könyvtárral töltheti le és gyorsítótárazhatja ezeket a kulcsokat.

Az E2B ES256 aláírások elfogadását, a várt kibocsátót és célközönséget, valamint a lejárati és érvényességi időket javasolja ellenőrizni. A szolgáltatás azt is vizsgálhatja, hogy a token tárgya a megfelelő projekthez és sandbox-végrehajtáshoz tartozik-e. Ezután a saját jogosultsági rendszeréhez kapcsolhatja az identitást, például egy sandboxot egy dokumentumfeldolgozási feladathoz rendelhet, és csak a hozzárendelt dokumentumot adhatja vissza.

BYOC-telepítéseknél saját kibocsátói URL és nyilvános kulcsok használhatók, amelyeket a támogatás állít be a Workload Identity engedélyezésekor.

Ideiglenes AWS-hozzáférés hosszú életű kulcsok nélkül

Az E2B példája szerint a háttérrendszer a beérkező JWT-t AWS Security Token Service-re cserélheti, majd ideiglenes jogosultságokkal olvashat egy S3-objektumot. Ehhez a token célközönsége sts.amazonaws.com, az AWS-fiókban pedig az E2B-t OpenID Connect szolgáltatóként kell regisztrálni.

A szerepkör bizalmi szabálya az E2B projektjéhez tartozó identitásokra korlátozható. Az STS a tokent az identitásszolgáltató és a szerepkör szabályai alapján ellenőrzi, majd ideiglenes hitelesítő adatokat ad ki. Az E2B bemutatott példájában ezek 15 perc után lejárnak, és nincs szükség hosszú életű AWS-hozzáférési kulcsokra.

A Workload Identity 2026. november 3-tól általánosan elérhető az E2B Cloudon. A szolgáltatás az E2B szerint olyan alkalmazásokhoz ad azonosítási réteget, ahol az ügynökök sandboxokon keresztül férnek hozzá a vállalati rendszerekhez, miközben az engedélyezett erőforrásokról és műveletekről továbbra is a háttérszolgáltatás dönt.