5 ms·

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again.

Except there is no secure docker runtime, and there never will be. If you want secure, you have tp put it in a VM , which gives you a performance penalty again. Secure means you can run arbitrary untrusted code, and webassembly cam do that, and docker can't.

cmeacham98 4y ago
There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker). This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.
- Thaxll 4y ago
  Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.
  - cmeacham98 4y ago
    I agree that Docker actually has a relatively good track record, but it is true that Docker will never be on the same level as a VM hypervisor that was designed from the ground up to be a security barrier. Thus, when people bring up "Docker is insecure" I try not to get down in the weeds arguing about the specifics, and instead point out alternative projects that are designed with security in mind. I find it's a much stronger counterargument.
  - ClumsyPilot 4y ago
    The world does not rely on docker for security at all, cloud providers put each tenant of container runtimes behind an additional barrier, like a VM. Secure runtimes are a superior solution to virtualisation and separate kernels. There are only two secure runtimes in common use - for javascriot and webassembly. The point about hardware support is very unfair - if you invest the same level of effort and hardware support into webassembly, you can also i prove its performance. Thats like compaining that electric cars suck because there are no chargers - its just infra.
- erk__ 4y ago
  I think that security has always been a goal of FreeBSD jails and I believe they are a bit more hardened than docker
  - vermaden 4y ago
    Docker only uses namespaces and cgoups. Docker does not provide and security or isolation. To have security and isolation with Docker you must use something external like SELinux or AppArmor. Hope that helps. Regards.
    - xvector 4y ago
      Docker also uses seccomp.
    - rapidlua 4y ago
      > Docker only uses namespaces and cgroups. How is that not isolation?
      - kaba0 4y ago
        The docker daemon has basically root over your system, so any escape can end very badly.
groestl 4y ago
Didn't say secure though, just isolated. Often I'm fine with some subset of isolation.
nine_k 4y ago
Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies. It's more like Flatpak or AppImage, only more popular and easy. This packaging also includes a kind of network insulation, exposing only the desired ports, making it easy to have VLANs between containers that do not interfere, etc. This is, again, not a serious security mechanism, but more of a convenience, but a very valuable convenience.
- mkher8 4y ago
  > Oh shucks. Docker's value proposition is emphatically not security. Congratulations, you have just discovered the additional value that WASM will bring to the Docker approach.
  - nine_k 4y ago
    WASM is the "run a proper VM" approach mentioned in the first line. WASM is great, but it solves a different problem.
- pxc 4y ago
  > Docker's value proposition is convenient, reproducible, self-contained packaging of software. Docker doesn't solve any packaging problems, though. It just piggybacks off of other package management solutions and allows ad-hoc, unmanaged modifications to OS images (the convenience) and contains that result for easy distribution. But nothing in that process ensures reproducibility— the package managers wrapped in Dockerfiles are typically non-deterministic: what any set of commands for them will do depends on the state of the internet at the time they run. Similarly, composing Docker layers is not like composing packages: reuse of packaged objects is minimal rather than maximal, granularity is course, dependency management details may vary from container to container (as they may be based on different Linux distros or language-specific package management ecosystems), and it's very easy to end up with software and configuration installed with which there is no associated package management metadata. Docker doesn't know anything about packages. Container scanning tools that do things like produce a bill of materials or scan for known vulnerabilities inside Docker containers simply have to guess at what distro is installed inside the container and then reconstruct that information in a distro-specific way to the best of their ability! Docker doesn't solve package management issues so much as punt on them (which is, of course, convenient, because package management is hard). > [Docker is] more like Flatpak [...] only more popular and easy. I don't think this is a sound comparison, either. Flatpak is a desktop-oriented containerization solution, for packaging graphical software that will predictably need to interact with the local filesystem, GPU, sound, and other resources. It's also a solution that tackles security updates and deduplication in a serious (and effective) way involving some discipline and enriching shared runtimes with actual metadata rather than just composing filesystem layers together. It may indeed be easier to crap out something which will be considered a valid Docker image than it is to crap out something which will be considered a valid Flatpak application, but that does not make Docker easier. It's not easier for a desktop user to keep a collection of 50 Docker containers patched for security fixes than it is for a desktop user to keep a collection of Flatpak applications patched for security fixes. It's not easier to take a random Docker container and plug it into your operating system's native file picker or sound system for use with graphical applications than it is to do so with a random Flatpak application. It's not easier to determine what the heck exactly is actually installed in a Docker container than it is to see what is in a Flatpak container. It is not easier to plug a random Docker application into your operating system's default password manager, and so on, and so on. Writing Flatpak packages requires actually thinking about things that Docker doesn't because Flatpak actually solves package management issues (and other things) that Docker doesn't.
cube2222 4y ago
Isn't gVisor a secure docker runtime? Sure, it doesn't reuse the kernel, but it's not a VM either.
jakogut 4y ago
> you have tp put it in a VM , which gives you a performance penalty This claim is dubious for many configurations of hardware accelerated virtualization. The hardware creates another ring 0 for each guest kernel, and guests run at the same level as the host. It's true that layering things like filesystems and networking incur overhead, but it's just as easy to pass through a physical disk, and bridge virtual TAP interfaces to physical NICs. Hardware virtualization is very flexible, and there's a configuration out there that will meet the performance requirements of the vast majority of projects.
- nine_k 4y ago
  A native code VM gives really little performance penalty. Consider VMs like those which run Javascript, or WASM. JIT compilation can get pretty close to C performance, as JVM and LuaJIT show though, given enough RAM at runtime, and money for development.
yjftsjthsd-h 4y ago
runq exists, and gvisor can be used as a docker runtime, so yes docker absolutely can.
drdaeman 4y ago
How many folks out there need to run arbitrary untrusted code on their systems? I think most of the time, the code they run is either their own or from a trusted third party. And for those use cases, where secure containment of running applications is not a goal at all (beyond maybe taking some basic precautions), I fail to see any value to recompile it to WASM, CLR, JVM, Z80 bytecode or whatever else. Those who need isolation - yeah, WASM could be a very solid alternative to having a VM. But it's a pretty niche use case.

cmeacham98 4y ago

There are serious attempts at secure container runtimes (see gVisor) and runtimes that run container images in a real VM (see Firecracker). This meme that containers are inherently insecure just because Docker doesn't attempt to be a security product needs to die. Docker hasn't been the only player in the container runtime space for a long time.

Thaxll 4y ago
Insecure is a very strong word, world has been running on Docker for sometime and it works fine and is not as insecure has you seem to think.
- cmeacham98 4y ago
  I agree that Docker actually has a relatively good track record, but it is true that Docker will never be on the same level as a VM hypervisor that was designed from the ground up to be a security barrier. Thus, when people bring up "Docker is insecure" I try not to get down in the weeds arguing about the specifics, and instead point out alternative projects that are designed with security in mind. I find it's a much stronger counterargument.
- ClumsyPilot 4y ago
  The world does not rely on docker for security at all, cloud providers put each tenant of container runtimes behind an additional barrier, like a VM. Secure runtimes are a superior solution to virtualisation and separate kernels. There are only two secure runtimes in common use - for javascriot and webassembly. The point about hardware support is very unfair - if you invest the same level of effort and hardware support into webassembly, you can also i prove its performance. Thats like compaining that electric cars suck because there are no chargers - its just infra.
erk__ 4y ago
I think that security has always been a goal of FreeBSD jails and I believe they are a bit more hardened than docker
- vermaden 4y ago
  Docker only uses namespaces and cgoups. Docker does not provide and security or isolation. To have security and isolation with Docker you must use something external like SELinux or AppArmor. Hope that helps. Regards.
  - xvector 4y ago
    Docker also uses seccomp.
  - rapidlua 4y ago
    > Docker only uses namespaces and cgroups. How is that not isolation?
    - kaba0 4y ago
      The docker daemon has basically root over your system, so any escape can end very badly.

groestl 4y ago

Didn't say secure though, just isolated. Often I'm fine with some subset of isolation.

nine_k 4y ago

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies. It's more like Flatpak or AppImage, only more popular and easy. This packaging also includes a kind of network insulation, exposing only the desired ports, making it easy to have VLANs between containers that do not interfere, etc. This is, again, not a serious security mechanism, but more of a convenience, but a very valuable convenience.

mkher8 4y ago
> Oh shucks. Docker's value proposition is emphatically not security. Congratulations, you have just discovered the additional value that WASM will bring to the Docker approach.
- nine_k 4y ago
  WASM is the "run a proper VM" approach mentioned in the first line. WASM is great, but it solves a different problem.
pxc 4y ago
> Docker's value proposition is convenient, reproducible, self-contained packaging of software. Docker doesn't solve any packaging problems, though. It just piggybacks off of other package management solutions and allows ad-hoc, unmanaged modifications to OS images (the convenience) and contains that result for easy distribution. But nothing in that process ensures reproducibility— the package managers wrapped in Dockerfiles are typically non-deterministic: what any set of commands for them will do depends on the state of the internet at the time they run. Similarly, composing Docker layers is not like composing packages: reuse of packaged objects is minimal rather than maximal, granularity is course, dependency management details may vary from container to container (as they may be based on different Linux distros or language-specific package management ecosystems), and it's very easy to end up with software and configuration installed with which there is no associated package management metadata. Docker doesn't know anything about packages. Container scanning tools that do things like produce a bill of materials or scan for known vulnerabilities inside Docker containers simply have to guess at what distro is installed inside the container and then reconstruct that information in a distro-specific way to the best of their ability! Docker doesn't solve package management issues so much as punt on them (which is, of course, convenient, because package management is hard). > [Docker is] more like Flatpak [...] only more popular and easy. I don't think this is a sound comparison, either. Flatpak is a desktop-oriented containerization solution, for packaging graphical software that will predictably need to interact with the local filesystem, GPU, sound, and other resources. It's also a solution that tackles security updates and deduplication in a serious (and effective) way involving some discipline and enriching shared runtimes with actual metadata rather than just composing filesystem layers together. It may indeed be easier to crap out something which will be considered a valid Docker image than it is to crap out something which will be considered a valid Flatpak application, but that does not make Docker easier. It's not easier for a desktop user to keep a collection of 50 Docker containers patched for security fixes than it is for a desktop user to keep a collection of Flatpak applications patched for security fixes. It's not easier to take a random Docker container and plug it into your operating system's native file picker or sound system for use with graphical applications than it is to do so with a random Flatpak application. It's not easier to determine what the heck exactly is actually installed in a Docker container than it is to see what is in a Flatpak container. It is not easier to plug a random Docker application into your operating system's default password manager, and so on, and so on. Writing Flatpak packages requires actually thinking about things that Docker doesn't because Flatpak actually solves package management issues (and other things) that Docker doesn't.

cube2222 4y ago

Isn't gVisor a secure docker runtime? Sure, it doesn't reuse the kernel, but it's not a VM either.

jakogut 4y ago

> you have tp put it in a VM , which gives you a performance penalty This claim is dubious for many configurations of hardware accelerated virtualization. The hardware creates another ring 0 for each guest kernel, and guests run at the same level as the host. It's true that layering things like filesystems and networking incur overhead, but it's just as easy to pass through a physical disk, and bridge virtual TAP interfaces to physical NICs. Hardware virtualization is very flexible, and there's a configuration out there that will meet the performance requirements of the vast majority of projects.

nine_k 4y ago
A native code VM gives really little performance penalty. Consider VMs like those which run Javascript, or WASM. JIT compilation can get pretty close to C performance, as JVM and LuaJIT show though, given enough RAM at runtime, and money for development.

yjftsjthsd-h 4y ago

runq exists, and gvisor can be used as a docker runtime, so yes docker absolutely can.

drdaeman 4y ago

How many folks out there need to run arbitrary untrusted code on their systems? I think most of the time, the code they run is either their own or from a trusted third party. And for those use cases, where secure containment of running applications is not a goal at all (beyond maybe taking some basic precautions), I fail to see any value to recompile it to WASM, CLR, JVM, Z80 bytecode or whatever else. Those who need isolation - yeah, WASM could be a very solid alternative to having a VM. But it's a pretty niche use case.