GKE Sandbox: Independent operating system kernel to each container

Re:GKE Sandbox: Independent operating system kernel to each ... by amscanne on Wednesday May 15, 2019 @06:35PM (#19924460)

I'm not sure what you mean by KVM syscall trapping for the guest. The bluepill refers to the fact that the Sentry runs transparently in VMX non-root ring 0 and regular host ring 3.

I'm not sure what to provide re: docs -- the code is all there, reasonably documented and there are discussions on the public groups of how the KVM platform works. I feel a bit like you're coming in with a specific set of ideas and skimming files (e.g. the performance guide and the code itself) in order to confirm an existing understanding, but it's just not working.

I'd love more precise criticisms re: adding to the attack surface, but otherwise I'm not sure how I can help.

[ Parent | on HN ]

Re:GKE Sandbox: Independent operating system kernel to each ... by muricula on Wednesday May 15, 2019 @07:07PM (#19924665)

I'm very skeptical about the platform and don't have the time to devote to reading the codebase or having conversations as I would like. The TL;DR is that the syscall interception technique seems expensive and I wonder if you will write all sorts of logic bugs in the sentry broker. It seems like you folks care about security, and have some good ideas, but if you really care about hostile multi-tenant containers, why not stick the container in a VM and call it a day?

[ Parent | on HN ]

Re:GKE Sandbox: Independent operating system kernel to each ... by yoshiat on Wednesday May 15, 2019 @10:13PM (#19925586)

I replied in other comments but our talk at Next'19 [1] includes a story by one of our customers, which may help understand the use cases. In a nutshell, GKE Sandbox should allow sharing the resources of GKE Nodes (VMs) among multiple tenants.

[1] https://www.youtube.com/watch?v=TQfc8OlB2sg

[ Parent | on HN ]