P4: Kata/VM isolation + intra-pod hardening (infra-gated)

[pdettori]

P4 — Kata/VM isolation + intra-pod cross-leaf hardening

Split out of #48 on 2026-07-03. Part of the two-tier FS-free harness epic #49. This is the security payoff of the two-tier split: the sandbox is the sole filesystem/syscall surface and the only tier that must be VM-isolated to contain a kernel exploit; harnesses stay on the default runtime.

Infra reality (why this is gated)

The live OCP 4.20 cluster is all m6i.xlarge — standard EC2, no /dev/kvm, so default nested Kata (QEMU/KVM) will not start. Options:

• bare-metal machine pool (.metal) — faithful Kata, expensive;
• Kata peer-pods (OpenShift sandboxed containers + cloud-api-adaptor) — isolation VM is a separate EC2 instance; runs on m6i workers but is its own build (podvm AMI, adaptor, IAM, extra $/cold-start);
• gVisor (runsc) — runs on m6i today, addresses kernel-exploit containment, but not OCP-productized and departs from the epic's 'Kata' wording.

Scope (when resumed)

1. Spike-then-decide infra path (bare-metal vs peer-pods vs gVisor) with a cost note; P4 may legitimately conclude 'defer with a documented plan'.
2. Run sandboxes under the chosen isolation RuntimeClass; carry runtimeClassName on the Sandbox CR podTemplate; verify agent-sandbox v0.5.0 compatibility.
3. Intra-pod cross-leaf isolation hardening — Kata-at-pod-level (one pod = one trust domain) and optionally per-leaf UID/namespace within a pod, reconciled with the shared /workspace/repo object store + per-leaf worktrees. Resolves the explicit P2 non-goal (soft dir-level isolation, shared UID 65532).
4. Kata-overhead delta measured on top of P3's E6 baseline (startup/overhead vs isolation trade-off).
5. RWX revisited — only if P3's E6 shows one sandbox is insufficient AND a fleet-wide single repo is wanted (EBS-only cluster has no RWX today).

Gate

Do not start until P3 experiments have produced a per-sandbox CAP + ratio baseline.