What is the difference between Ignite and gVisor in terms of their use-case?

Question

I would like to know if there is a difference between gVisor and Weave Ignite in terms of their use-cases (if there is any). To me, both of them seem to try a similar thing: make the execution of code in virtualized environments more secure.

gVisor is doing this by introducing runsc, a runtime that enables sandboxed containers and Ignite is doing it by using Firecracker, which in their context also seems to be used as a sandbox.

Answer 1

Both Firecracker and gVisor are technologies which provide sandboxing / isolation but in a different way.

• Firecracker (orange box) is a Virtual Machine Manager.
• gVisor (green box) has an architecture which controls/filters the system calls that reach the actual host.

Weave Ignite is a tool that helps you use Firecracker in order to run containers inside lightweight VMs and also do that with a nice UX, similar to using Docker.

This is also mentioned in the Scope section of github.com/weaveworks/ignite

Scope

Ignite is different from Kata Containers or gVisor. They don't let you run real VMs, but only wrap a container in new layer providing some kind of security boundary (or sandbox).

Ignite on the other hand lets you run a full-blown VM, easily and super-fast, but with the familiar container UX. This means you can "move down one layer" and start managing your fleet of VMs powering e.g. a Kubernetes cluster, but still package your VMs like containers.

Regarding the use-case part of your question, it's my feeling that because of the stronger isolation VMs offer, Ignite can be more production-ready. Also, the approach of gVisor seems to have a significant performance cost, as it is mentioned at The True Cost of Containing: A gVisor Case Study:

Conclusion

• gVisor is arguably more secure than runc
• Unfortunately, our analysis shows that the true costs of effectively containing are high: system calls are 2.2× slower, memory allocations are 2.5× slower, large downloads are 2.8× slower, and file opens are 216× slower

---

Current Sandboxing Methods

Sandboxing with gVisor

Do I Need gVisor?

No. If you're running production workloads, don't even think about it! Right now, this is a metaphorical science experiment. That's not to say you may not want to use it as it matures. I don't have any problem with the way it's trying to solve process isolation and I think it's a good idea. There are also alternatives you should take the time to explore before adopting this technology in the future.

Where might I want to use it?

As an operator, you'll want to use gVisor to isolate application containers that aren't entirely trusted. This could be a new version of an open source project your organization has trusted in the past. It could be a new project your team has yet to completely vet or anything else you aren't entirely sure can be trusted in your cluster. After all, if you're running an open source project you didn't write (all of us), your team certainly didn't write it so it would be good security and good engineering to properly isolate and protect your environment in case there may be a yet unknown vulnerability.

---

---

Further reading

My answer has information from the following sources which are in quote sections when taken "as-is" and I recommend them for further reading:

• What is gVisor? from Rancher Blog
• Making Containers More Isolated: An Overview of Sandboxed Container Technologies
• Containers, Security, and Echo Chambers blog by Jessie Frazelle
• The True Cost of Containing: A gVisor Case Study
• Kata Containers vs gVisor?
• Firecracker: Lightweight Virtualization for Serverless Applications paper from AWS
• gVisor Security Basics - Part 1 from gVisor blog