14

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.

tgogos
  • 23,218
  • 20
  • 96
  • 128
User12547645
  • 6,955
  • 3
  • 38
  • 69

1 Answers1

18

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

enter image description here


Sandboxing with gVisor

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.


enter image description here


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:

tgogos
  • 23,218
  • 20
  • 96
  • 128
  • 1
    Thank you very much for the answer and the furhter reading section! :) – User12547645 Jul 12 '19 at 12:46
  • 1
    @User12547645 today I bumped into this: [The True Cost of Containing: A gVisor Case Study](https://www.usenix.org/system/files/hotcloud19-paper-young.pdf) *"simple syscalls are at least 2.2× slower on gVisor; worse, opening and closing files on an external tmpfs is 216× slower. I/O is also costly; reading small files is 11× slower, and downloading large files is 2.8× slower."* (from [Cindy Sridharan](https://twitter.com/copyconstruct/status/1151373786345693184)) – tgogos Jul 17 '19 at 07:13
  • 1
    Windows WSL1 subsystem has a similar architecture to gVisor where I/O performance is very slow and noticeable. WSL2 is more like Firecracker from my understanding where they have thrown away emulated linux kernel and run a real kernel. Performance went way up. – Kashif Shaikh Mar 30 '20 at 20:58