why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
I am not sure why this got downvoted, it is a valid question which got an informative response.
Breaking Out of Docker via RunC
11–20 of 21 posts
Re: Breaking Out of Docker via RunC
#12why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
I am not sure why this got downvoted, it is a valid question which got an informative response.
Because it's a hyperbolic rhetorical question. Security teams don't just unilaterally ban things without context, especially things that provide significant business value. It's about threat modeling and what the risk is in practice for the company and use case in question.
Re: Breaking Out of Docker via RunC
#13Earlier quoted context omitted.
I am not sure why this got downvoted, it is a valid question which got an informative response.
Because it's a hyperbolic rhetorical question. Security teams don't just unilaterally ban things without context, especially things that provide significant business value. It's about threat modeling and what the risk is in practice for the company and use case in question.
Good security teams*. I have definitely experienced overzealous bad security.
Re: Breaking Out of Docker via RunC
#14This is a really great exploration of this vulnerability. It makes me sad that lxc doesn't get more love. LXC has had unprivileged containers as its default for 5+ years now. Its a really solid tool set that has mostly been passed over for lack of marketing.
Need to be careful that Docker and LXC both default to unprivileged, however they use the term to mean different things.
If you say “don’t run your containers as root on the host”, this matches the issue better.
Re: Breaking Out of Docker via RunC
#15why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
Allowing your users to run something as root inside a container should violate a security audit. And yes, Docker is almost irresponsible to continue defaulting to root.
But containers themselves should not -- there are plenty of security benefits to using containers. There is no real difference between an LXC container and a runc container besides the fact that Docker defaults to running thing as root and without user namespaces. That is obviously a bad decision, but it's not an indictment of containers as a concept.
Re: Breaking Out of Docker via RunC
#16why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
We think of these as deployment abstractions that provide no security value. This is why services like Amazon’s ECS Fargate pair 1 task definition (usually a single container) to a single EC2 host for isolation.
If you use user namespaces and don't run as host root, they provide a clear security value (unless your alternative is that you use user namespaces in your program, at which point you are making your own container runtime). Docker's (and LXC's) default seccomp profile has blocked something like 95% of kernel 0days since they were added, for instance.
Re: Breaking Out of Docker via RunC
#17why isn't docker and k8s banned by security teams? these are clearly broken abstractions that would violate most security audits immediately
We think of these as deployment abstractions that provide no security value. This is why services like Amazon’s ECS Fargate pair 1 task definition (usually a single container) to a single EC2 host for isolation.
AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.
Re: Breaking Out of Docker via RunC
#18Earlier quoted context omitted.
We think of these as deployment abstractions that provide no security value. This is why services like Amazon’s ECS Fargate pair 1 task definition (usually a single container) to a single EC2 host for isolation.
AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.
Something I've been wondering for a while (and you may be placed to answer): is firecracker part of the isolation story for Fargate - or is it regular EC2 instances?
Re: Breaking Out of Docker via RunC
#19This is very interesting, because most docker break outs I see are exploits in the linux kernel, but this is one of the few in the containerization components themselves (first one I remember in runC).
Definitely not the first.
There was one with leaking file descriptors which weren't opened with O_CLOEXEC.
Another with ptrace (fixed by making the process non-dumpable).
Re: Breaking Out of Docker via RunC
#20Earlier quoted context omitted.
AWS employee here! The relationship is actually one task per EC2 _instance_ (VM isolation), not one task per host. I'm sure you meant the former, but just wanted to clarify for readers.
Something I've been wondering for a while (and you may be placed to answer): is firecracker part of the isolation story for Fargate - or is it regular EC2 instances?