You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit fc7caf2
Browse filesBrowse the repository at this point in the historyBrowse files
refactor(supervisor): launch sandbox instances from one config and prepared bindings
Replace SandboxRunConfig and its field-by-field copy into
SandboxInstanceConfig with a single launch configuration. Live per-instance
state (gateway credentials, OCSF context and JSON settings, log sink, and
denial log) is now an explicit SandboxInstanceBindings value that the owner
prepares once, instead of placeholders the runner or host overwrote.
The dedicated binary loads launch inputs from its arguments and environment
and shares one GatewayCredentials with log push; run_sandbox_with_backend
keeps the process-wide OCSF context, health endpoints, and signal handling.
The instance host binds the same SandboxInstanceBindings to its runtime
threads and revokes their credentials when the instance ends.
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Copy file name to clipboardExpand all lines: crates/openshell-supervisor/README.md
+25-20Lines changed: 25 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ The supervisor loads and reconciles policy, maintains provider credentials, appl
4
4
5
5
## Backend startup
6
6
7
-
The public `run_sandbox` entry point selects the OpenShell Sandbox Protocol backend and collects its startup inputs into a public `SandboxRunConfig`. Shared startup receives that config and the trusted backend setup separately. The `backend_setup` module owns that backend's launch-data decoder, workload policy discovery, and client construction. Descriptor contents cannot select an implementation.
7
+
The supervisor binary selects a backend setup and collects its launch inputs into a public `SandboxInstanceConfig`. Shared startup receives that config and the trusted backend setup separately. The `backend_setup` module owns that backend's launch-data decoder, workload policy discovery, and client construction. Descriptor contents cannot select an implementation.
8
8
9
9
Shared startup checks the admitted backend name before passing the opaque payload to its decoder. It then compares the decoded sandbox, session, and runtime generation with the trusted launch inputs before installing credentials or discovering workload policy. A mismatch stops startup.
10
10
@@ -14,7 +14,7 @@ The supervisor admits policy and prepares credentials before constructing and at
14
14
15
15
The client receives the supervisor's live provider state, bearer-token slot, and CA-path slot. Provider refresh, token rotation, and later CA publication must remain visible through those shared handles. Startup does not create independent copies of their current values.
16
16
17
-
`backend_setup`, `SandboxRunConfig`, and `run_sandbox_with_backend` are public so the supervisor binary can select a registered backend. External backends should implement the `IsolationBackend` and `SandboxProtocol` services rather than link this crate.
17
+
`backend_setup`, `SandboxInstanceConfig`, `SandboxInstanceBindings`, and `run_sandbox_with_backend` are public so the supervisor binary can select a registered backend. External backends should implement the `IsolationBackend` and `SandboxProtocol` services rather than link this crate.
18
18
19
19
The startup result separates the backend transport payload from optional
20
20
authenticated CONNECT listener settings. Shared networking starts the listener
@@ -29,27 +29,32 @@ Gateway connections, and the gateway supervisor sessions carried over them,
29
29
can reconnect within an instance without creating another one; the generation
30
30
remains the fencing identifier.
31
31
32
-
`run_sandbox_instance` supervises one sandbox instance from a
33
-
`SandboxInstanceConfig` and `SandboxInstanceControls`. Everything that belongs
34
-
to that instance is an input or is created by the instance: gateway
35
-
credentials and their renewal, the Sandbox Protocol credential, policy,
36
-
provider credentials and token grants, middleware credentials, OCSF JSON
37
-
settings, proxy trust files, the denial history served by `policy.local`, the
38
-
backend connection, access plane, readiness, and stop signal. Gateway clients
39
-
receive a `GatewayEndpoint`, which pairs the URL with that instance's
40
-
`GatewayCredentials`; nothing is installed process-wide.
41
-
42
-
`run_sandbox_with_backend` is the dedicated wrapper. It keeps the existing
43
-
process contract: it sets the process-wide OCSF context, reads launch inputs
44
-
from the environment, binds the readiness socket and port to instance
45
-
readiness, and stops the instance on SIGTERM or SIGINT. The binary shares one
46
-
`GatewayCredentials` between log push and supervision, so renewal by either
47
-
keeps both current.
32
+
`run_sandbox_instance` supervises one sandbox instance from three inputs.
33
+
`SandboxInstanceConfig` is the single launch configuration: identity, command,
34
+
policy inputs, auth bundle, backend descriptor, and file locations.
35
+
`SandboxInstanceBindings` is the live state its owner prepares once: the
36
+
`GatewayCredentials` issued from the auth bundle, the OCSF context and JSON
37
+
settings, the log sink, and the denial history served by `policy.local`.
38
+
`SandboxInstanceControls` carries the owner's stop signal and readiness.
39
+
Everything else, including credential renewal, policy, provider credentials and
40
+
token grants, middleware credentials, the backend connection, and the access
41
+
plane, is created by the instance. Gateway clients receive a `GatewayEndpoint`,
42
+
which pairs the URL with that instance's `GatewayCredentials`; nothing is
43
+
installed process-wide.
44
+
45
+
The dedicated process wrapper keeps the existing process contract. The binary
46
+
loads the launch configuration from its arguments and environment and prepares
47
+
`SandboxInstanceBindings::dedicated`, sharing one `GatewayCredentials` with log
48
+
push and the OCSF JSON settings with its logging layers, so renewal by either
49
+
gateway client keeps both current. `run_sandbox_with_backend` sets the
50
+
process-wide OCSF context, binds the readiness socket and port to instance
51
+
readiness, and stops the instance on SIGTERM or SIGINT.
48
52
49
53
`sandbox_instance_host::SandboxInstanceHost` runs several sandbox instances in
50
54
one process. Each instance gets its own Tokio runtime; every thread of that
51
-
runtime, and the thread driving it, is bound to the instance's OCSF context,
0 commit comments