Azure-Samples / Azure-Samples/azure-container-apps-sandboxes
Spike: run the sample test harness inside a sandbox (sandbox-as-host)
- Dominant language
- Python
- Stars
- 15
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
## Idea
Explore running the sample test harness *inside* an ACA sandbox, so the samples are exercised by the same primitive they demonstrate (test sandboxes using sandboxes). `04-swarms/02-shared-blob-memory` already proves the dataplane half of this: the orchestrator is itself a sandbox that spawns worker sandboxes via managed identity.
## Why it is interesting
- Dogfooding: the harness becomes a first-class sandbox use case.
- Ephemeral, egress-controlled execution with a short-lived scoped identity instead of a standing runner credential.
- Hermetic environment for the dataplane-only samples (boot + exec + volumes).
## The hard part: control plane vs dataplane
`setup.py` and the swarm samples need control-plane writes (create resource group + sandbox group, assign the Sandbox Data Owner role). That is a host-role privilege. Putting an identity that can mint groups and grant RBAC *inside* a sandbox widens the blast radius and inverts the isolation the samples exist to teach. It would also require opening egress to ARM and the dataplane endpoints, which dilutes the deny-by-default story.
## Proposed bounded experiment
- Pre-provision the group plus a scoped managed identity *outside* (on the runner, host role, as designed today).
- Inside a sandbox-as-host, run only the dataplane-only LIGHT samples (05-data-processing pipeline, the egress scenario) using that scoped identity.
- Keep egress locked to ARM plus the dataplane endpoints only.
- Measure whether it adds correctness signal over the current OIDC GitHub Actions runner, or whether the value is primarily dogfooding.
## Non-goals
- Do not replace the OIDC-runner e2e job; this is a parallel spike.
- Never place the RBAC-granting (control-plane) identity inside the sandbox.
## Outcome
A short writeup plus a throwaway branch demonstrating (or ruling out) the sandbox-as-host harness for the LIGHT tier, with a recommendation on whether to invest further.
Contributor guide
Research direction
Start with setup.py and the existing 04-swarms/02-shared-blob-memory sample to understand the current sandbox orchestration and identity setup. Run the LIGHT dataplane-only samples, especially 05-data-processing and the egress scenario, inside a sandbox-as-host with the proposed restrictions. Done means a throwaway branch and short writeup showing whether the harness works, its correctness signal, and a recommendation on further investment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, github-actions, python
- Domain
- cloud, devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100