Add isolated-container routing and deployment profile #1132

Summary

Provide a separately deliverable container-isolated profile where a trusted gateway authenticates users and routes each principal to a dedicated Piclaw container. Containers share the host kernel; operators/host administrators retain access. The documented boundary depends on hardened container, mount and network configuration.

Acceptance criteria

• isolated-containers mode requires explicit gateway trust configuration and fails closed when it is absent.
• Gateway supports the same per-user TOTP and WebAuthn account lifecycle as family mode.
• Gateway maps immutable user IDs to backend IDs and health state.
• Identity assertions are signed, short-lived, audience-bound and replay-resistant.
• Backend containers reject unsigned browser-provided identity headers.
• Each user container has separate workspace, database, session data, keychain and process namespace by default.
• CPU, memory, process and network policy can be configured per backend.
• Shared skills use versioned packages or a read-only mount with explicit provenance.
• Optional shared files use an explicit mount or broker and display the resulting reduction in isolation.
• Gateway preserves sticky WebSocket/SSE routing and restart reconnection.
• Settings shows backend assignment, version, health and storage usage to administrators.
• Backup, restore, upgrade and rollback procedures operate per user and for the gateway.

Gateway and isolation contract

• Implement one authentication authority at the gateway, reusing Add per-user TOTP and WebAuthn account lifecycle #1125; backends receive validated identity without copying user factors. Define gateway versus backend roles independently of access.mode. Backends are never exposed as unauthenticated single-user services on a public port.
• Provision backend assignments statically/through an operator-controlled management surface initially; backend IDs resolve through an allowlisted registry, never user-supplied URLs. Ordinary tenant containers receive no Docker socket or provisioning credentials.
• Terminate TLS/WebAuthn at the stable public origin/RP, strip incoming identity headers, and authenticate gateway-to-backend transport (mTLS or equivalent). Specify signed assertion issuer, immutable actor/owner, audience/backend, expiry, key rotation and replay validation without forwarding signing keys.
• Carry validated identity through every backend request/run via Propagate authenticated user identity into model execution #1129. Make revocation/disablement close active streams and deny reconnects; gateway errors/unreachable backends never fall back to another account, shared instance or untrusted identity.
• Use non-root containers without privileged mode, host PID/network namespaces, broad capabilities, passwordless host sudo or host Docker socket. Isolate writable volumes, secrets and networks; limit access to sibling backends, gateway/admin ports and host services. Define egress/provider access and resource quotas.
• Test HTTP, SSE, WebSocket, media/upload/viewer URLs, popouts, cookies, service-worker cache scope and account switching through the gateway. Use one backend per request; no cross-backend cookie/static/private cache leakage.
• Read-only shared skills/references or versioned packages preserve shared code distribution; writable collaborative volumes are optional and explicitly weaken confidentiality/integrity. Separate workspace/credential/backup data remains private to its backend.
• Provide repeatable Compose/operator manifests with separate gateway and per-user persistent volumes, scoped backup/restore, key handling, health/upgrade/rollback/version checks and measured idle/warm memory cost. VM isolation is required if sharing a host kernel is unacceptable.
• This issue is a later milestone. Family release and its documentation can ship first; mark this mode unavailable until its end-to-end gate passes. Redesign Settings for account, session and family administration #1130 supplies common UX, while this issue owns conditional backend-assignment/health integration.

Test plan

• Two-container cross-user filesystem, database, keychain and network-isolation tests.
• Signed assertion expiry, audience and replay tests.
• SSE/WebSocket reconnect and rolling-upgrade tests.
• Shared read-only skill mount tests.

Definition of done

• Acceptance criteria and negative cases are verified with evidence linked here.
• Relevant unit/integration and single-user compatibility tests pass; typecheck passes for code changes.
• User-facing behaviour, migration and operational limits are documented.
• No mode is enabled before its integrated release gate in Add migration, security regression, operations and documentation gates #1133.

Configuration and delivery details

• Use domains.access.isolation.component and the gateway/backend schemas from Define modes, user schema and backward-compatible migration #1123. Only the gateway owns user factors/browser sessions; each backend validates assertions for its configured audience/owner. Setting access.mode without a valid component role never exposes anonymous/default backend access.
• Break implementation into bounded gateway identity/proxy, container deployment/health and private/shared storage/operations slices. Create native nested workitems if a slice exceeds one reviewable PR; retain the family-independent delivery gate.

Tracking

• Draft ID: MU-10
• Dependencies: Define modes, user schema and backward-compatible migration #1123, Resolve authenticated principals and expose /auth/me #1124, Add per-user TOTP and WebAuthn account lifecycle #1125, Propagate authenticated user identity into model execution #1129
• Parent: Add configurable multi-user modes with user-bound session trees #1134