Aporeto's efforts in securing containers using Xen-based virtualization technologies are moving forward. After PVCalls, a new approach to virtual machine networking, we introduced a Xen transport for 9pfs. Exporting a filesystem from host to guest is an essential requirement for many containers engines. Together, the two protocols lay the foundation for VM-based containers. This talk will introduce the new Xen 9pfs protocol. It will explain its design and performance. The presentation will describe the best way to integrate Xen into container engines. It will discuss the challenges of introducing Xen support into CoreOS rkt, and provide an update on the upstreaming effort. It also will demonstrate rkt deploying cloud-native apps seamlessly as virtual machines on Xen, and detail the benefits of this approach and the differences with traditional containers deployments.

4. Linux Kernel
Linux Namespaces
Docker Registry
Linux Namespaces
Cloud-Native App
Linux Namespaces
Cloud-Native App
App binaries
App libraries
Cloud-Native
App
App binaries
App libraries
CoreOS rkt

6. The problem with
Linux namespaces

7. Cloud-native
App
Cloud-native
App
Linux kernel
POSIX
Cloud-native
App

8. Cloud-native
App
Cloud-native
App
Linux kernel
POSIX
Large surface of attack
On average, 3 privilege
escalation vulnerabilities per
Linux release!
Cloud-native
App

9. Cloud-native
App
Malicious App
Linux kernel
POSIX
Cloud-native
App
Large surface of attack
On average, 3 privilege
escalation vulnerabilities per
Linux release!

10. Cloud-native
App
Malicious App
Linux kernel
POSIX
Cloud-native
App
Large surface of attack
On average, 3 privilege
escalation vulnerabilities per
Linux release!

11. Cloud-native
App
Malicious App
Linux kernel
POSIX
Cloud-native
App
Large surface of attack
On average, 3 privilege
escalation vulnerabilities per
Linux release!

12. Cloud-native
App
Malicious App
Linux kernel
POSIX
Cloud-native
App
Large surface of attack
On average, 3 privilege
escalation vulnerabilities per
Linux release!

16. App
(Container)
same owner
App
(Container)
same owner
Linux kernel
App
(Container)
same owner
Cloud-native
App
same owner
Cloud-native
App
same owner
Linux kernel
POSIX
Cloud-native
App
same owner
Xen
● No multi-tenancy
● Only run cloud-native apps from
the same user on the same host
● Use VMs (or bare-metal) as
security boundary
● Need to handle both VMs
provisioning and Cloud-Native
app provisioning
Virtual interface, on average:
Xen PV: 1 priv escalation vuln / year
KVM: 4 priv escalation vuln / year

17. Introducing Stage1-Xen
https://github.com/rkt/stage1-xen

18. Xen
VM
Docker Registry
VM
Cloud-Native App
VM
Cloud-Native App
App binaries
App libraries
Cloud-Native
App
App binaries
App libraries
CoreOS rkt

19. Cloud-native
App
Cloud-native
App
Linux
Cloud-native
App
Xen
POSIX
Linux Linux
VMX
VM
● Fully transparent
● Secure by default: no need to
worry on which host cloud-native
apps are running
● Mix and match traditional VMs
and cloud-native apps on a single
platform
● Work on bare-metal and on the
cloud
● Support apps monitoring

20. Why Xen?

22. ●
●

24. PVCalls

26. Cloud-native App
Linux DomU
Xen
POSIX
PV Interface
VM
Each app is run in a small separate
Xen VM for isolation.
POSIX calls are confined within the
VM, “emulated” by the guest kernel.
Few selected syscalls are handled
securely by Dom0 (filesystem and
socket syscalls primarily).
Dom0
PV Calls

27. Dom0Cloud-native app
Xen
PV Interface
VM
Syscall
backend
Syscall
frontend
PV Calls
All other
syscalls
Linux DomU internals

31. Fin