You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Containers in linux are primarily a shipping method (as Docker themselves try to inform you with the visual of a shipping container).
Just like real shipping containers, dangerous things inside can leak out - the isolation is not foolproof by any means, in fact if someone has the express wish of violating the isolation boundary it's barely an inconvenience.
I don't think that's the whole story. There's no documented way to escape the container. The kernel provides namespace isolation which should be foolproof by design. You might argue, that there were many bugs which allowed to escape the container and probably more bugs will be found in the future. However it does not mean, that it's fair to call it "inconvenience". I don't know any zero-day bugs in Linux and probably neither you. And it would take me a lot of effort to even attempt to find one.
Maybe the default form of RUN is kinda sorta safe [0].
How about ADD? Or COPY? Or RUN —-mount=type=bind,rw…?
Over the last ten years or so we’ve progressed from subtle-ish security holes due to memory unsafety and such to shiny tools in shiny safe languages that have absolutely gaping security and isolation holes by design. Go us.
[0] There is some serious wishful thinking involved there.
I'm confused--what's the security risk in building a container?
Fundamentally building a container involves running a container - each layer is executed in turn as a temporary container.
The same risks that running an unknown container has - are had by building one.
For reference there have been quite a few CVEs related to container escape: https://www.paloaltonetworks.com/blog/cloud-security/leaky-v...
You're running untrusted code. Every RUN command in a user's Dockerfile is executed during build, which means you're executing arbitrary commands from strangers on your own infrastructure. If you're not isolating that properly, it's a security risk.
Inside the container though. The whole point of which is that it sandboxes and isolates the running code.
Containers in linux are primarily a shipping method (as Docker themselves try to inform you with the visual of a shipping container).
Just like real shipping containers, dangerous things inside can leak out - the isolation is not foolproof by any means, in fact if someone has the express wish of violating the isolation boundary it's barely an inconvenience.
I don't think that's the whole story. There's no documented way to escape the container. The kernel provides namespace isolation which should be foolproof by design. You might argue, that there were many bugs which allowed to escape the container and probably more bugs will be found in the future. However it does not mean, that it's fair to call it "inconvenience". I don't know any zero-day bugs in Linux and probably neither you. And it would take me a lot of effort to even attempt to find one.
This blog post[1] explains why that is not a safe assumption.
[1]: https://www.aquasec.com/blog/container-isolation/
Maybe the default form of RUN is kinda sorta safe [0].
How about ADD? Or COPY? Or RUN —-mount=type=bind,rw…?
Over the last ten years or so we’ve progressed from subtle-ish security holes due to memory unsafety and such to shiny tools in shiny safe languages that have absolutely gaping security and isolation holes by design. Go us.
[0] There is some serious wishful thinking involved there.
containers are not virtualization. they only provide lightweight isolation as they share the host kernel.
so if you want sandboxing and proper isolation -- use a VM.
https://learn.microsoft.com/en-us/virtualization/windowscont...