Summary
The Azure Sandboxes hosting integration should automatically grant a consuming application's managed identity the permissions needed to create and manage sandboxes at runtime, following Aspire's reference-based role-assignment pattern for other Azure integrations.
Scenario
An ASP.NET Core controller deployed to Azure Container Apps Express accepts a user prompt and creates a fresh Azure sandbox to run a Python agent. The controller needs Container Apps SandboxGroup Data Owner on the sandbox group to create sandboxes, execute commands, and delete them.
The AppHost is written in TypeScript. The desired configuration is conceptually:
const express = await builder.addAzureContainerAppEnvironment('express').asExpress();
const sandboxes = await builder.addAzureSandboxGroup('sandboxes');
const identity = await builder.addAzureUserAssignedIdentity('controller-identity');
await builder.addProject('controller', '../Controller/Controller.csproj')
.withComputeEnvironment(express)
.withAzureUserAssignedIdentity(identity)
.withReference(sandboxes);This illustrates the desired reference-based experience, rather than a verified minimal reproduction of the reference call's current behavior.
Current behavior / evidence
With Aspire CLI/SDK 13.6.0 and Aspire.Hosting.Azure.Sandboxes 13.6.0-preview.1.26475.12:
- The generated sandbox-group Bicep includes a
deploymentPrincipalDataOwner assignment using userPrincipalId / principalType for the deployment identity.
- That identity is distinct from the controller's runtime managed identity.
- The application currently passes sandbox-group ID/location outputs to the controller and needs a custom Bicep module to grant its runtime identity access.
- The generated TypeScript SDK has no sandbox-specific role-assignment helper analogous to
withFoundryRoleAssignments.
The required role definition ID is c24cf47c-5077-412d-a19c-45202126392c (Container Apps SandboxGroup Data Owner).
This was identified by inspecting generated deployment artifacts and the integration source. A live Azure authorization failure has not been reproduced.
Expected behavior
Referencing a sandbox group from a consuming compute resource should:
- Use Aspire's existing managed-identity and default-role-assignment machinery to grant Container Apps SandboxGroup Data Owner, scoped to the referenced sandbox group, to the consumer's runtime identity.
- Work from both C# and TypeScript AppHosts, including when the consumer is deployed to a different compute environment such as ACA Express.
- Expose the sandbox connection metadata needed by the consumer (resource ID, location/data-plane endpoint) through the normal reference experience.
- Preserve the separate deployment-principal assignment and support the usual explicit-role overrides / default-role opt-out behavior where applicable.
Declaring a sandbox group alone should not grant unrelated applications access; the resource reference should express the permission requirement.
Workaround
Add a custom Bicep module to the AppHost that declares the sandbox group as existing and creates a Microsoft.Authorization/roleAssignments resource scoped to it, using the controller managed identity's principal ID. This works around the missing declarative runtime-access experience but requires hand-written RBAC infrastructure for a first-party integration.
Suggested coverage
Add tests verifying that a referencing controller receives a scoped runtime role assignment, an unrelated resource does not, and the deployment identity remains separate from the runtime identity.
Summary
The Azure Sandboxes hosting integration should automatically grant a consuming application's managed identity the permissions needed to create and manage sandboxes at runtime, following Aspire's reference-based role-assignment pattern for other Azure integrations.
Scenario
An ASP.NET Core controller deployed to Azure Container Apps Express accepts a user prompt and creates a fresh Azure sandbox to run a Python agent. The controller needs Container Apps SandboxGroup Data Owner on the sandbox group to create sandboxes, execute commands, and delete them.
The AppHost is written in TypeScript. The desired configuration is conceptually:
This illustrates the desired reference-based experience, rather than a verified minimal reproduction of the reference call's current behavior.
Current behavior / evidence
With Aspire CLI/SDK 13.6.0 and
Aspire.Hosting.Azure.Sandboxes13.6.0-preview.1.26475.12:deploymentPrincipalDataOwnerassignment usinguserPrincipalId/principalTypefor the deployment identity.withFoundryRoleAssignments.The required role definition ID is
c24cf47c-5077-412d-a19c-45202126392c(Container Apps SandboxGroup Data Owner).This was identified by inspecting generated deployment artifacts and the integration source. A live Azure authorization failure has not been reproduced.
Expected behavior
Referencing a sandbox group from a consuming compute resource should:
Declaring a sandbox group alone should not grant unrelated applications access; the resource reference should express the permission requirement.
Workaround
Add a custom Bicep module to the AppHost that declares the sandbox group as existing and creates a
Microsoft.Authorization/roleAssignmentsresource scoped to it, using the controller managed identity's principal ID. This works around the missing declarative runtime-access experience but requires hand-written RBAC infrastructure for a first-party integration.Suggested coverage
Add tests verifying that a referencing controller receives a scoped runtime role assignment, an unrelated resource does not, and the deployment identity remains separate from the runtime identity.