Document the rootless worker posture and commit its seccomp profile

[ppXD]

Summary

• Commit backend/deploy/seccomp/codespace-worker.json. It is moby v20.10.20's default profile resolved for a container with no capabilities, plus one unconditional allow of the seven calls bubblewrap needs (clone, clone3, mount, pivot_root, setns, umount2, unshare).
  • With it, plus apparmor=unconfined and systempaths=unconfined, the unmodified worker image confines as uid 1654. It needs no --privileged and no capability, and a network-off child sees only loopback.
  • The file is in OCI runtime-spec form, with no includes, excludes or archMap. containerd decodes a Localhost profile straight into specs.LinuxSeccomp (contrib/seccomp/seccomp.go) and silently drops those keys. A moby-format file would therefore have become an unconditional allow of 39 capability-gated calls on the Kubernetes path, among them the new mount API, open_by_handle_at, bpf and process_vm_readv/writev.
  • derive-codespace-worker.sh regenerates the file from the sha256-pinned moby source.
• Rewrite the Dockerfile.worker confinement header per tier, with a Kubernetes securityContext for the same posture (hostUsers: false, procMount: Unmasked, Localhost seccomp, AppArmor Unconfined, non-root, drop ALL; privileged: true with runAsUser: 1654 on older clusters). Two old statements were wrong:
  • an allowlist run on an unprivileged pod aborts at launch rather than "just gets Denied";
  • an allowlist run also needs CAP_SYS_ADMIN, because ip netns add needs it.
• Add a commented security_opt block to docker-compose.yml; the default stack is unchanged. Both the compose comment and the Dockerfile say that a masked /proc still passes the bubblewrap probe (the probe mounts no /proc) while every launch fails. An operator should therefore check that the first run's agent starts, not rely on the boot line alone.
• Log one Sandbox posture: line at worker boot. It gives the bubblewrap probe and its reason, whether the codespace-mcp helper is present, and whether FilteredEgressNetns.CanSeal holds and why not.

Test plan

• Unit: RootlessWorkerPostureTests (13):
  • the seven calls are allowed unconditionally;
  • none of the other 39 calls moby gates on a capability is allowed;
  • only OCI LinuxSeccomp/LinuxSyscall keys appear, so Docker, containerd and CRI-O read one filter;
  • the file's SHA-256 is pinned to the derivation;
  • the boot line carries each probe.
• Unit: full suite (11330 passed, 1 skipped)
• E2E: RecurringJobWorkerSmokeE2ETests.The_worker_host_logs_its_sandbox_posture_once_at_boot. It boots the real Worker-role host and fails if the registrar stops emitting the line.
• Integration: HangfireHostingRoleTests, SandboxConfigurationStartupTests (25)
• Sandbox lane, privileged: BubblewrapConfinementSandboxTests, DurableLaunchEgressE2ETests, SealedEgressE2ETests, CommandIsolationE2ETests (26), no host residue
• Container proof: worker image, not privileged, arm64 kernel.
  • uid 1654 under the profile: confines, and the network-off child has only lo.
  • Same with drop ALL + no-new-privs under containerd's reading of the file.
  • Four capability-gated calls return EPERM under both the Docker and the containerd reading.
  • Profile with pivot_root removed: the probe reports unavailable and RequireConfinement refuses.
  • root + NET_ADMIN + SYS_ADMIN under the profile: confines, and CanSeal holds.
• Mutations: widening the rule, removing pivot_root, adding a capability-gated rule or an archMap key, and deleting the registrar call each turn a test red.
• amd64 node: confirm the worker confines under the profile (only arm64 has been measured).
• containerd 2.x node: confirm it reads the Localhost profile as the emulated reading did.