Learn Firecracker - Security Model & Hardening

#Introduction

In episode 7 we installed the jailer; in episode 13 we isolated the network. Episode 14 weaves everything together into one complete security model — and closes the gaps operators often forget.

Why is this episode important? Firecracker is used for untrusted workloads: code from users we don't trust. The entire value of a serverless product depends on how deeply we understand its threat model — what's protected, from whom, and with what mechanisms. This episode is what separates a sandbox that's genuinely secure from one that merely looks secure.

#KVM Hardware Isolation vs Container Escapes

The most misunderstood question: what's the security difference between containers and microVMs?

• Containers share the host kernel. Isolation depends on namespaces, cgroups, seccomp, and Linux capabilities. If there's a kernel bug (a CVE in namespaces or LSMs), all containers on the host are affected.
• MicroVMs run their own guest kernel under KVM. Isolation depends on virtualization hardware. To break out, an attacker must leap two layers: guest kernel → hypervisor (KVM + Firecracker) → host kernel.

Escaping a container is "leveling up" one kernel. Escaping a microVM means penetrating two kernels and a hypervisor — a far narrower attack surface. This is why AWS moved Lambda from multi-tenant containers to VM-level isolation: a much wider security margin.

But that margin is only real if Firecracker itself is treated as breachable code. That's where hardening comes in.

#Seccomp Profiles: The Syscall Whitelist

Seccomp restricts the syscalls the Firecracker process may call. Firecracker installs a strict seccomp profile at startup — only the syscalls the VMM needs are allowed, everything else is rejected with SIGSYS.

Seccomp hardening practices:

• Don't loosen the profile without a strong reason. Every added syscall is a potential attack.
• Test workloads on the standard profile first; if a syscall is genuinely needed, add it explicitly and document it.
• Watch the architecture: profiles differ between x86_64 and aarch64 — don't copy profiles across architectures.

Firecracker's seccomp profile is stored in the binary directory and selected by architecture. Verify that the jailer loads it:

ps -o pid,comm,seccomp,user -C firecracker

A seccomp column value of 2 (filter mode) means the profile is active.

#Landlock and LSMs

Seccomp limits syscalls; LSMs (Linux Security Modules) and Landlock limit object access — files, directories, networks. Landlock lets a process restrict its filesystem access to a whitelist without root: the Firecracker process can only read the files it should (kernel, rootfs) and can't touch the rest.

The ideal combination:

• Seccomp: limits what can be done (syscalls).
• Landlock: limits what can be reached (filesystem).
• Namespaces + chroot: limits the world it lives in.

Together, the three form overlapping layers — one fails, the other two still hold. This is the essence of defense-in-depth.

#The Jailer as Defense-in-Depth

The jailer (episode 7) isn't an alternative to seccomp — it's a complement. If seccomp is a safety net at the syscall level, the jailer is a prison at the process level: separate network namespaces, its own cgroup, a non-root user, chroot, read-only rootfs.

Firecracker's final security model for untrusted workloads:

1. The guest is isolated by KVM from the Firecracker process.
2. The Firecracker process is caged by the jailer (namespace, cgroup, chroot, read-only).
3. Syscalls are limited by seccomp.
4. Object access is limited by LSM/Landlock.

If the guest is breached → it lands in the Firecracker process → it meets seccomp and the jailer → it can't write files, can't make dangerous syscalls, has no privileges. The host stays intact.

#The CVE Patching Cadence

Security never finishes. Firecracker regularly publishes fixes — the latest example: v1.16.1 (July 2, 2026) fixed CVE-2026-5747 in the virtio PCI initialization validation. Lessons from CVEs like this:

• Always follow releases: watch the release page and the official CHANGELOG.
• Understand the impact: CVE-2026-5747 relates to virtio devices — imperfect validation could be exploited by a guest. Severity determines patch speed.
• Schedule rolling updates: a multi-node cluster can be patched progressively without downtime; but don't delay a version fixing a critical CVE.
• Record the versions in use: an inventory of Firecracker + jailer versions per node simplifies audits and patch planning.

CVEs are an unavoidable part of running a sandbox. What separates professional operators is the rhythm: monitor → triage → patch → verify.

#Production Hardening Principles

A checklist you can apply directly:

1. Never give global CAP_NET_ADMIN — TAPs and namespaces per VM, not global host privileges. If one VM is compromised, it must not create its own interfaces.
2. Minimal devices — only install the devices the workload uses. Don't need vsock? Don't enable it. Every device is an attack surface.
3. Deny hardware passthrough — unless supported by the kernel with a clear mechanism (e.g. VFIO with isolation), don't expose host devices to the guest.
4. Read-only rootfs — the guest must not be able to modify its system.
5. Network deny-by-default — only the routes the workload needs.
6. Rate limiters on all I/O devices — prevent one VM from taking down the host with an I/O flood.
7. Control plane isolation — the API socket can only be accessed by authorized processes (strict socket file permissions).

#Common Pitfalls

• Running Firecracker as root: erases every benefit of the jailer — always non-root.
• Using the wrong-architecture seccomp profile: an x86_64 profile on an aarch64 host is inactive or crashes.
• TAPs in the host namespace with global privileges: give per-VM privileges, not global CAP_NET_ADMIN.
• Skipping security releases: unpatch CVEs → weak sandbox; monitor releases routinely.
• Excess devices: unused vsock, entropy, and balloon devices are unnecessary attack surface.

#Closing

The key takeaways:

• MicroVMs add a KVM hardware isolation layer on top of container isolation.
• Seccomp limits syscalls; Landlock limits object access; the two complement each other.
• The jailer is defense-in-depth that assumes the VMM can be breached.
• CVE patching is a mandatory cadence — example: CVE-2026-5747 in v1.16.1.
• Hardening: no global CAP_NET_ADMIN, minimal devices, deny passthrough, read-only rootfs, rate limiters.

In the next episode 15 we'll look at the future direction of Firecracker security: Confidential Computing & Trusted Guests — attestation and trusted VMs, Firecracker's position in the Kubernetes ecosystem, the limitations that remain, and distributing secrets safely via MMDS and TLS without exposing metadata to the internet.