Firecracker introduces AWS - “micro-virtualization” for Linux

On AWS re: Invent 2018, which is taking place these days in Las Vegas, Firecracker was announced - a new open source virtualization technology based on Linux KVM. The authors promise that “in a split second you can run lightweight micro-virtual machines (microVMs) in a non-virtualized environment, gaining the advantages of traditional VMs - in the form of security and isolation of workloads, and containers - in the form of efficient use of resources”.

Prehistory

The development of Firecracker is backed up by Amazon Web Services employees, who set themselves the goal of improving resource consumption and life in general for users of services such as AWS Lambda (started in 2014 and allows us to declare today that the serverless model will continue to exist) and AWS Fargate (appeared a year ago ).

The basis for the project was the open source development from Google - crosvm from Chromium OS, which is written in Rust and is responsible for launching operating systems with virtualization of devices (but without emulating real hardware). Therefore, the Firecracker code is also written in the Rust language , and its authors promise to return their corrections to the code base of the parent project, although the projects themselves have diverged greatly in their purpose over time.

The first public release of Firecracker - 0.1.0 - took place in March of this year, and the last actual release - 0.11.0 - just a few days ago. I started writing this article shortly after the Firecracker Internet announcement, when the project had 76 stars on GitHub, and at the time of publication this figure had already exceeded 500.

Firecracker Features

The main component of Firecracker is the virtual machine monitor (VMM), which uses Linux KVM to create and run so-called microVMs. The authors call their product "a cloud alternative to QEMU" [used in Kata Containers], "intended only for safe and efficient launch of containers."

And this is how an example of a host system is illustrated in which the mentioned microVMs are running:

Developers strive for minimalism, including in the product only the most necessary and thus ensuring minimal memory costs, and at the same time reducing the possibilities for potential vulnerabilities. Only 4 devices are emulated in Firecracker: virtio-net, virtio-block, serial console and keyboard with 1 button used to stop the microVM. As a host and guest operating systems, the OS currently supports OS based on Linux kernel version 4.14 ( release from November last year) and above, and in the current plans of developers - to support the last two stable Linux kernel branches. In terms of hardware, only Intel processors are currently supported, but AMD and ARM appear in the plans.

Firecracker itself consists of a single VMM process that, when launched, makes the endpoint (RESTful) API available on the host machine. The API itself is described.in the OpenAPI format and, in particular, allows you to run microVM with the specified parameters (kernel image, root file system, boot arguments) and stop it, configure virtual machines (number of vCPUs, RAM, template for CPU), add network interfaces to them , disks (presented as block devices, read-write and read-only modes available), configure the system for logs and metrics.

The main advantages of Firecracker are security (orientation to multi-tenant computing, several isolation levels), high performance (microVM can be launched in 125 ms, and the authors promise to improve this figure next year), the minimum overhead (each microVM consumes about 5 megabytes of memory). What adds weight to the project is that it has already been tested “in combat” and ensures the operation of a number of AWS services (including those mentioned by Lambda and Fargate).

Security Details

Among the main features of Firecracker, focused on providing a high level of security, the following are mentioned:

A simple guest model (for all guests only the very minimum is provided - see above about 4 devices).
Isolating the Firecracker process using cgroups and seccomp BPF, as well as a limited set of allowed system calls.
Static linking of the Firecracker process to run it in isolation from the host environment.

Firecracker demonstration

The AWS blog showed how microVMs can be tried in action. To do this, it is enough to create an i3.metal instance and load 3 files onto it (executable file firecracker, root filesystem image, Linux kernel):

Then install the necessary rights on / dev / kvm:

$  sudo setfacl -m u:${USER}:rw /dev/kvm

Set the configuration for the first guest machine:

$ curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT "http://localhost/machine-config" \
    -H "accept: application/json" \
    -H "Content-Type: application/json" \
    -d "{
        \"vcpu_count\": 1,
        \"mem_size_mib\": 512
    }"

... then the core for her:

$ curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT "http://localhost/boot-source" \
    -H "accept: application/json" \
    -H "Content-Type: application/json" \
    -d "{
        \"kernel_image_path\": \"./hello-vmlinux.bin\",
        \"boot_args\": \"console=ttyS0 reboot=k panic=1 pci=off\"
    }"

... and root FS:

$ curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT "http://localhost/drives/rootfs" \
    -H "accept: application/json" \
    -H "Content-Type: application/json" \
    -d "{
        \"drive_id\": \"rootfs\",
        \"path_on_host\": \"./hello-rootfs.ext4\",
        \"is_root_device\": true,
        \"is_read_only\": false
    }"

It remains to actually run the guest:

# curl --unix-socket /tmp/firecracker.sock -i \
    -X PUT "http://localhost/actions" \
    -H  "accept: application/json" \
    -H  "Content-Type: application/json" \
    -d "{
        \"action_type\": \"InstanceStart\"
     }"

Result:

What about other container projects?

Although the authors of Firecracker promise to “integrate with popular container executables”, this is what they answer to the question of whether the project can be used with Kubernetes, Docker or Kata containers:

"Not yet. We are developing Firecracker as an open source project because it offers a significantly different approach to security in launching containers. We hope that other communities creating open source technologies for containers will find it useful. We are working to ensure Firecracker’s natural integration into the container ecosystem — in order to realize seamless integration in the future, providing more options for isolating container workloads. ”