Repository navigation
Support declarative artifact delivery and stable endpoint for governed sandboxes #2818
Description
Activity
📋 triage-agent
Triage Assessment
Classification: needs-information
Summary
The issue describes useful security and lifecycle invariants, but it does not
yet establish the concrete user story or explain why existing and in-progress
OpenShell lifecycle primitives cannot be composed to support the workflow.OpenShell already has gateway-owned service endpoints that bind to an
immutable sandbox ID, fail closed unless the sandbox is Ready, and are removed
during sandbox teardown. Issue #2710
and PR #2726 introduce a
canonical supervised main process, while
PR #2798 adds gateway-owned
restart policies.These capabilities may cover much of the request if the digest-pinned bridge
can run as the sandbox's canonical main process. A distinct feature would
still be needed if the bridge must be delivered as an additional artifact,
run as an auxiliary managed process, use application-specific readiness, or
move an endpoint between different OpenShell sandbox IDs.Information requested
Please update the issue with:
- A user story identifying the control plane, the workload it manages, and
the desired outcome. - The current workflow and why composing a digest-pinned sandbox image, the
canonical main process, its restart policy, and the existing service
endpoint API would not satisfy it. - Whether the bridge is:
- the sandbox's canonical main process,
- an auxiliary process within the same sandbox policy boundary, or
- an independently isolated service.
- Whether “sandbox replacement” means replacing the backing process or pod
while preserving the OpenShell sandbox ID, or creating a new sandbox ID
for the same logical workload. - The readiness signal required before endpoint activation, such as process
liveness, a TCP connection, an HTTP probe, or an authenticated application
report.
If replacement creates a new sandbox ID, please also describe which explicit
control-plane operation should authorize moving the stable endpoint. A
same-named sandbox should not inherit the previous sandbox's endpoint or
authority automatically.Once this context is available, we can determine whether the request is an
existing-capability composition/documentation task or a new managed-process,
readiness, or endpoint-handoff capability.- A user story identifying the control plane, the workload it manages, and
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
Thanks @elezar — answering directly.
-
User story. A control plane provisions a sandbox for an untrusted workload and must attach its own digest-pinned bridge process, reachable on a stable authenticated address other services use. The control plane supplies only digest-pinned, independently verified artifact coordinates; OpenShell owns installation, lifecycle, routing, and teardown. The address always resolves to the currently-active sandbox, fails closed during replacement, and a replaced sandbox never inherits the prior authority.
-
Why the current composition falls short. The canonical main (feat(sandbox): add canonical main process #2726) + restart policy (feat(sandbox): add main restart policy #2798) + service endpoint cover a single, image-supplied, liveness-gated workload on one sandbox. The topology work (feat(kubernetes): add proxy-pod topology (in-pod process supervisor, out-of-pod proxy) #2885, feat(kubernetes): add cni-sidecar supervisor topology #2606) and
SandboxProfile.trustedInjection(Proposal: Split Supervisor and Agent into Separate Pods with gVisor Isolation #981) add image-volume delivery — but only for trusted OpenShell components launched as the entrypoint. Support declarative artifact delivery and stable endpoint for governed sandboxes #2818 needs four things outside that: an auxiliary managed process alongside the workload, not the canonical main; caller-supplied digest-pinned delivery — independently verified, not an OpenShell component, not baked into the image — reusing thetrustedInjectionmechanism rather than pod exec/copy; an application-level readiness gate before endpoint activation, not main-process liveness; and endpoint continuity bound to the sandbox's immutable identity across replacement. -
The bridge is an auxiliary managed process in the same sandbox policy boundary — its own digest-pinned image, run as the sandbox's identity — not the canonical main, not an independent service.
-
Replacement means a new runtime instance, not a reused sandbox ID. feat(kubernetes): add proxy-pod topology (in-pod process supervisor, out-of-pod proxy) #2885 already keys companions on the immutable sandbox UUID and refuses name reuse; Support declarative artifact delivery and stable endpoint for governed sandboxes #2818 extends that so the artifact and endpoint bind to the UUID and a replacement provisions a fresh instance the endpoint re-targets once ready. A same-named successor never inherits the prior endpoint or authority.
-
Readiness is an authenticated application report, not liveness/TCP/HTTP. If replacement creates a new instance, an explicit control-plane operation binds its identity before the endpoint follows — never name-based adoption.
Once you classify it, we'll contribute the neutral integration test.
-
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
Problem
A control plane needs to deliver a digest-pinned bridge artifact to a sandbox and expose it through a stable, replacement-safe endpoint. The pinned SDK currently exposes a whole
SandboxSpec.image, environment, labels, and providers, but no declarative artifact/sidecar delivery or endpoint lifecycle surface.Using a controller-created Kubernetes Service selector or direct pod exec/copy is unsafe here: a sandbox replacement can reuse names while changing identity, and it bypasses the gateway lifecycle.
Requested capability
Please provide (or document a supported composition of) a gateway-owned API that lets a caller:
The caller can supply only digest-pinned, independently provenance-verified artifact coordinates. OpenShell should remain responsible for artifact installation, process lifecycle, routing, and teardown.
Acceptance evidence
We can contribute a neutral integration test once a proposed API/contract is available.