Skip to main content
A sandbox that needs to reach your cloud account should never hold a long-lived cloud key. Instead, a sandbox running as a workload mints a short-lived, audience-bound JWT from the deployment’s workload-identity issuer and exchanges it directly with your cloud through its native workload-identity federation. No static credential is stored anywhere and no refresher daemon runs in the guest: AWS and Google Cloud tokens are minted on demand rather than parked in a default token file, and the Microsoft Entra lane writes only its explicit SDK fallback token file, on boot-local tmpfs.
Steps 1 and 2 below work today. Step 3 does not yet: hiloop sandbox create has no workload declaration, so a sandbox cannot be launched as a workload and carries no ambient identity for hiloop workload-identity to mint against. You can register federation and configure the cloud-side trust now, but do not build a flow that depends on the in-sandbox exchange until the sandbox lane lands. See workload identity.
The flow has three parts: register the federation (owner/admin, once per workload and cloud), configure the trust on the cloud side (once), and use it from inside the sandbox.

​
1. Register the federation

Federation is registered per workload, per cloud. The token audience is derived server-side from the registered descriptor, so a workload can only request tokens for audiences an owner or admin registered — the registration list is the workload’s token-audience allowlist.
Google Cloud registrations take --project-id, --project-number, --pool-id, and --provider-id (plus optional --service-account-email to impersonate). Microsoft Entra registrations take --application-id and --entra-tenant-id.

​
2. Configure the cloud-side trust

federation setup prints the exact, copyable trust configuration for one registration — read-only, it never changes your cloud account:
The generated trust policy pins the deployment’s issuer and the workload’s subject (org:<id>:workload:<id>), so the mapping is exact and auditable on both sides. For AWS, --organization-wide widens the trust from one workload to every workload in the organization; the pattern stays organization-pinned. Two operational notes: Microsoft Entra allows at most 20 federated identity credentials per application, and a typo in issuer/subject/audience is often accepted at creation and fails only at exchange — verify the exact values if an exchange is rejected.

​
3. Use it inside the sandbox

This is the shape the sandbox lane will take, and it is not reachable yet (see the warning above). Once a sandbox can run as the workload, hiloop workload-identity wires the cloud SDKs to the ambient identity. setup prints the exact SDK wiring for every registered federation descriptor (pass --cloud aws|gcp|azure to narrow it):
The commands it wires, per cloud — tokens are minted on demand:
hiloop workload-identity token --audience <audience> mints one raw federation JWT to stdout when you need to drive an exchange yourself. Every audience must be on the workload’s registered allowlist — an unregistered audience is refused.

​
Revoke

Removing a registration revokes the audience on the hiloop side immediately:
The trust object you created in the cloud account is yours — remove it there separately.

​
Why this shape

  • Nothing to leak. There is no long-lived cloud key in the sandbox, its environment, its workspace, or the platform’s stores.
  • Attribution on both sides. A cloud API call made this way carries the workload’s pinned subject in your cloud audit log and the workload’s name in the hiloop run record.
  • Scoped by construction. The audience allowlist is registered per workload by an owner or admin, and your cloud trust policy decides exactly what that audience may do.