3 ms·

(I'm a co-author of the blog post) I generally agree re: trope, but it's useful because I'm not sure the core idea is widely understood outside security circle

(I'm a co-author of the blog post) I generally agree re: trope, but it's useful because I'm not sure the core idea is widely understood outside security circles. Many people assume that containers provide a strong isolation boundary, and while a break-out is not trivial, providing more isolation in some cases is important, as you allude. While one option is certainly to provide a locked down policy, monitor the flow of kernel CVEs, and patch constantly, this may not be feasible for many organizations if a) they lack the technical expertise or b) don't know the workloads they're running a priori and can't apply a fixed policy. So different container runtimes are about providing additional tools for defense-in-depth. (VMs are fantastic tool for this, but it's also nice to have tools that play well in containerized infrastructure other than custom security policies.) None of these tools will be perfect of course, hopefully they can make it easier to improve on the status quo. Re: contained.af, this is a great example of the workloads problem. If you have a known workload where you can essentially disable all capabilities and access to system resources (e.g. no network), there are many options for securing that workload. They aren't all generalizable.

raesene9 7y ago
Oh I'd agree and gVisor provides (IMO) a smaller attack surface than a default runc container. With that said both options, and indeed hypervisor based isolation, are generally one security flaw away from a breakout vulnerability, so the only difference in that respect is the incidence of those flaws. My experience of people's expectations of container isolation is perhaps somewhat different to yours, which is what prompted my initial comment. It's all too common (in my experience) to see container isolation dismissed using that "containers don't contain" trope, and for me that feels frustrating as the real picture is much more nuanced than that. It's all about choosing the right isolation technology for a) a given workload and b) a given threat model/attack surface. There are tradeoffs (both in terms of performance, and in terms of flexibility) in replacing the runc layer with a different container runtime. Sometimes those will make sense, other times not so much :) All that said I'm very excited to see more options here, as it'll give everyone the choice of what mechanism works for them for specific workloads.

raesene9 7y ago

Oh I'd agree and gVisor provides (IMO) a smaller attack surface than a default runc container. With that said both options, and indeed hypervisor based isolation, are generally one security flaw away from a breakout vulnerability, so the only difference in that respect is the incidence of those flaws. My experience of people's expectations of container isolation is perhaps somewhat different to yours, which is what prompted my initial comment. It's all too common (in my experience) to see container isolation dismissed using that "containers don't contain" trope, and for me that feels frustrating as the real picture is much more nuanced than that. It's all about choosing the right isolation technology for a) a given workload and b) a given threat model/attack surface. There are tradeoffs (both in terms of performance, and in terms of flexibility) in replacing the runc layer with a different container runtime. Sometimes those will make sense, other times not so much :) All that said I'm very excited to see more options here, as it'll give everyone the choice of what mechanism works for them for specific workloads.