Jailer and security baseline¶

The launcher Pod is useful for qualification but is privileged host-management code. The security experiment therefore also launched a native microVM through the matching Firecracker jailer binary and inspected the host process after InstanceStart.

Verified baseline¶

Before InstanceStart, the API process showed seccomp mode 0. After startup, all four VMM threads showed seccomp mode 2 with one installed filter. Security checks must therefore inspect the post-start VMM, not infer the final posture from the preboot API process.

Deployment requirements¶

• Pin and verify a matching Firecracker/jailer pair.
• Use one unprivileged identity and one non-reused chroot per instance.
• Make kernel, rootfs, and configuration inputs immutable to the jail UID.
• Create only the device nodes required by the selected VM configuration.
• Set explicit cgroup, rlimit, NUMA, CPU, memory, network, and cleanup policy.
• Authenticate and restrict access to the Firecracker API socket.
• Treat TAP creation, image staging, jail construction, and cleanup as privileged control-plane operations with an audit trail.
• Verify the effective process after start: namespaces, capabilities, NoNewPrivs, seccomp mode, cgroup membership, open descriptors, and mounts.

The test instance is intentionally retained on the dedicated lab node for follow-up work. That is acceptable for an isolated experiment, but production controllers must guarantee teardown after normal exit, API failure, VMM crash, node reboot, and interrupted creation.

Limits of this result¶

This smoke test confirms that the documented isolation controls became active; it is not a penetration test or proof of multi-tenant safety. Guest escape, malicious block images, device emulation, kernel attack surface, host service access, and cleanup races require separate adversarial testing.

Primary references¶

• Firecracker jailer
• Firecracker seccomp filters
• Firecracker design