Harden and pool the Firecracker cloud computer runtime #7

Project

Cloud computer platform

Source: Cloud computer scale architecture audit

Outcome

Turn the existing Agent Computer Firecracker provisioner into a hardened, pooled runtime provider for the strong cloud computer class. Do not enable multi-tenant fan-out while the live path launches Firecracker directly without jailer or equivalent containment.

Current gaps

• crates/oa-codex-control/src/cloud_vm.rs launches Firecracker directly and states NOT jailer in the launch path.
• Each current guest reserves 4 vCPUs and 8 GiB, while the observed live host is n2-standard-4.
• Provisioning copies a complete writable root filesystem for each run.
• The inspected TAP and network-address-translation path does not establish the required per-workspace default-deny egress policy.
• The current implementation does not provide a multi-host placement, drain, or warm-pool scheduler.

Scope

• Run Firecracker under jailer or a documented equivalent with namespaces, cgroups, seccomp, a constrained chroot, dedicated runtime users, and bounded device access.
• Enforce per-lease CPU, memory, process, file-descriptor, scratch, network, and wall-clock limits.
• Use immutable base images and copy-on-write overlays instead of full root filesystem copies.
• Add a host agent that reports allocatable capacity, active leases, image-cache state, health, cleanup evidence, and quarantine state.
• Place supported nested-virtualization hosts in a dedicated managed instance group with zone spread, drain, replacement, and image rollout controls.
• Use supported host families such as N2 or qualified alternatives. Measure the documented nested-virtualization CPU and input/output overhead.
• Replace general guest egress with a default-deny broker and block the Google metadata service.
• Use generation-bound reverse-dial credentials and vsock or another constrained guest control channel.
• Add a small global warm pool whose members have no owner data or reusable credentials.
• Define and benchmark separate standard and strong resource profiles before changing the current 4-vCPU, 8-GiB profile.

Deliverables

• Hardened Firecracker launch and teardown implementation.
• Host agent, placement adapter, managed instance group configuration, and host image pipeline.
• Copy-on-write image and workspace integration.
• Network and metadata isolation.
• Capacity, health, drain, replacement, and zero-residue receipts.
• Escape, exhaustion, host-loss, and cleanup fault suites.

Acceptance criteria

• A guest process cannot reach host files, host credentials, the metadata service, another guest, or another workspace.
• CPU, memory, process, scratch, and network exhaustion remain confined to one lease.
• Host drain and loss move eligible workspaces to a new generation without duplicate command execution.
• Teardown proves zero processes, TAP devices, mounts, overlays, cgroups, credentials, and scratch residue.
• Any failed cleanup quarantines the lease or host and prevents capacity reuse.
• Warm runtimes contain no previous owner data and receive fresh generation-bound credentials.

Dependencies

Depends on #3, #4, #5, and #6. Coordinate the security gate with the cross-provider isolation issue in this project.