feat(permissions): add the sandbox permission sets

[ItamarZand88]

Summary

Adds the four cloud permission sets a sandbox needs — provision, management, execute and heartbeat — so a deployment can build a sandbox image, start and stop sessions, and run code in one, each with only the access that job requires.

The sets divide along one line: reaching inside a live session is separate from managing sessions.

1. provision builds and tears down the image a session launches from, and tags it — that tag is the boundary everything else scopes against.
2. management starts, stops and lists sessions. It can end a session it cannot read.
3. execute mints the credential that reaches inside a session, and is the only set that does. This is the line the whole split exists to draw.
4. heartbeat counts sessions and reads image metadata, and nothing else.

A resource link hands a workload execute, so anything a workload should not have has to live outside it.

What I did

Each cloud authorizes these operations differently, and the sets follow the platform rather than a house shape:

• AWS authorizes every MicroVM operation against the image, not the running MicroVM — there is no resource type for a running one. So RunMicrovm, TerminateMicrovm, SuspendMicrovm, ResumeMicrovm, GetMicrovm and the auth-token mint are all scoped to this sandbox's own image ARNs. Three actions (CreateMicrovmImage, ListMicrovmImages, ListMicrovms) are authorized against no resource type at all; creation is bounded by boundary tags in the request instead, and the two list actions are name-only reads.
• Azure exposes session lifecycle and session contents as separate data actions, so management takes the lifecycle four and execute takes the role that carries the data plane.
• GCP has no entry, and needs none: a GCP sandbox is a subprocess of the workload's own instance, so it creates no cloud resource.

Files touched

• crates/alien-permissions/permission-sets/sandbox/*.jsonc — the four sets.
• crates/alien-permissions/src/generators/azure_runtime.rs — one role-id mapping.
• crates/alien-permissions/tests/* — the invariant and coverage tests below.

How I tested

• Checked every action in the four sets against the pinned AWS IAM dataset and the Azure provider-operations dataset the repository already validates against, confirming each action's required resource type matches what the set binds it to. This is what a scoped role will actually enforce, and it is not something a deployment test would surface — broad credentials never refuse.
• Extended the sensitive-content invariant to name the Azure actions that reach inside a session, then confirmed by mutation that putting one of them into management fails the test. It passed before the change, which is why the test was extended.
• Confirmed by mutation that the tag condition on image creation is load-bearing: removing it fails the wildcard-resource test.
• Confirmed by mutation that an unscoped MicroVM ARN now fails the scoping test. Two exemptions previously described these actions as impossible to scope; both were removed, and the statements they covered are checked again.
• cargo test -p alien-permissions — 134 tests.

Security review of this diff, since these grants are what a customer's cloud enforces:

• A management, provision or heartbeat holder reaching session contents — refused by construction and pinned by test on both clouds; the auth-token mint and the Azure data-plane role appear in execute alone.
• A workload reaching another stack's sandbox — every MicroVM statement is scoped to image ARNs carrying this stack's prefix, and image creation carries the stack, resource and managed-by tags in the request.
• A workload reaching another sandbox in its own stack — the resource binding narrows further, to the sandbox's own name.
• An interactive shell into a session — CreateMicrovmShellAuthToken is granted nowhere, and is named in the test constants so adding it has to be deliberate.
• Wildcard resources — the three that carry one are the actions AWS authorizes with no resource type; creation is tag-conditioned and the other two are reads.

Nothing turned up.

[greptile-apps]

Greptile Summary

The PR adds provision, management, execute, and heartbeat permission sets for sandbox resources while separating session-content access from lifecycle and monitoring permissions.

• Adds AWS and Azure grants for sandbox image provisioning, session lifecycle, execution credentials, and heartbeat metadata.
• Restricts Azure execute, management, and heartbeat grants to individual sandbox-group resource bindings.
• Adds Azure predefined-role resolution and updates Terraform emission to skip unsupported stack targets for resource-only grants.
• Extends provider-operation coverage and sensitive-permission invariants for the new sandbox capabilities.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
crates/alien-permissions/permission-sets/sandbox/execute.jsonc	Adds execution-only AWS token minting and an Azure Data Owner assignment scoped to one sandbox group.
crates/alien-permissions/permission-sets/sandbox/heartbeat.jsonc	Adds metadata-only heartbeat grants and limits Azure access to the bound sandbox group.
crates/alien-permissions/permission-sets/sandbox/management.jsonc	Adds session lifecycle permissions without session-content credentials and removes Azure stack-level scope.
crates/alien-permissions/permission-sets/sandbox/provision.jsonc	Adds image and sandbox-group provisioning grants with AWS creation-tag conditions and documented Azure creation scope.
crates/alien-permissions/src/generators/azure_runtime.rs	Maps the Container Apps SandboxGroup Data Owner role name to its Azure role identifier.
crates/alien-terraform/src/emitters/azure/helpers.rs	Avoids requesting unsupported stack grants from permission sets that intentionally expose only resource bindings.
crates/alien-permissions/tests/azure_runtime.rs	Verifies execute, management, and heartbeat cannot generate stack-scoped Azure grants while resource grants remain available.
crates/alien-permissions/tests/aws_sensitive_invariant.rs	Classifies MicroVM session-content credentials as sensitive implicit actions.
crates/alien-permissions/tests/azure_sensitive_invariant.rs	Classifies Azure sandbox command, file, and Data Owner capabilities as sensitive.
crates/alien-permissions/tests/aws_abac_validation.rs	Requires request-tag constraints for wildcard-scoped MicroVM image creation.
crates/alien-permissions/tests/operation_coverage.rs	Adds critical provider-operation coverage for sandbox provisioning, execution, and management.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Provision["sandbox/provision"] --> Parent["Sandbox image or group"]
  Management["sandbox/management"] --> Lifecycle["Create, list, stop sessions"]
  Execute["sandbox/execute"] --> Contents["Commands and file access"]
  Heartbeat["sandbox/heartbeat"] --> Metadata["Parent state and session counts"]
  Parent --> Lifecycle
  Lifecycle --> Contents

Loading

_{Reviews (19): Last reviewed commit: "feat(permissions): add the sandbox permi..." | Re-trigger Greptile}