Support Firecracker

[jackevans43]

Previous discussed elsewhere, @fidencio suggested raising an issue here.

Can/should the OpenShift implementation of Kata containers support Firecracker? AWS trust Firecracker to isolate lambda functions from different users running on the same physical machine - that is an exceptionally high security bar. QEMU is great, but I'd argue Firecracker provides a higher level of isolation due to not being a general purpose implementation and being focused on simplicity and security, uses Rust etc.

Why would you want the option of a higher level of isolation?

• Running workloads with enhanced separation. If someone compromise an Internet facing container in my cluster, I want to be confident they couldn't break out onto the host.
• Running untrusted workloads. Maybe I want to do something crazy like automated malware analysis within containers.

[zanetworker]

@jackevans43 Firecracker is very focused on serverless use-cases, while that might be something we could support in the future on the operator (with QEMU), it is not our only use-case. In our case, we are using a minimal version of QEMU, which covers most of the use-cases. I would like to point out that both Firecracker and QEMU are meant to isolate via virtualization. In fact, Firecracker might suffer in-terms of networking performance (e.g., does not use vhost networking), it also only supports block storage and lacks support for host-guest file-sharing which is crucial to the functionality of Kubernetes / OpenShift [1][2].

With this operator, we are only supporting QEMU as the VMM atm.

[1] kata-containers/runtime#1071
[2] kata-containers/documentation#351