8 ms·

why not? I would argue, that they use linux namespacing, cgroup etc.

tyingq 6y ago
I agree that containers are something of a security boundary, as is chroot(). Just not as robust a boundary as an actual VM.
imtringued 6y ago
It's not good enough for multi tenant setups. A single malicious customer can potentially steal data from other customers. The docker team also considers security to be a pretty low priority.
- jamiesonbecker 6y ago
  To say nothing of sidechannel attacks[0] People need to stop looking at containers as a cheap way to get security. They might be a more convenient way to get lots of apps running on a single machine, but they're not very secure. https://ieeexplore.ieee.org/document/7847002 https://ieeexplore.ieee.org/document/7847002
  - CodesInChaos 6y ago
    1. I expect people to move towards a VM per pod model, even in private setups. Firecracker claims a memory overhead of 5 MB, and a minimal QEMU setup shouldn't be too bad either. 2. It sounds like this paper is mainly about covert channels not side channels. Covert channels assume cooperation between both sides, so they're only relevant if one of the sides can't communicate trivially (e.g. via network)
    - jamiesonbecker 6y ago
      > vm per pod .. firecracker agreed. AWS gets a lot of flak, but open sourcing firecracker was really great. I'd really prefer to see us move toward vms instead of containers, even if we kept the same k8s abstractions. > .. covert .. thanks for the catch, should have taken more time. Here's a better paper: https://hal.inria.fr/hal-01591808/document https://hal.inria.fr/hal-01591808/document
      - CodesInChaos 6y ago
        > I'd really prefer to see us move toward vms instead of containers, even if we kept the same k8s abstractions 1. For me containers are one of those abstractions, defined by exposing an application controlled userspace. Containers can be implemented by different isolation technologies, from simple chroot/cgroup/namespaces... to VMs. 2. I'd still use chroot&co to partially isolate containers within a pod, while using VMs to strongly isolate pods from each other. This enables features like shared block-devices, unix-domain-sockets and monitoring the processes in an application container from a separate diagnostics container.
CodesInChaos 6y ago
In theory it is a security boundary. But the attack surface is so big, and local privilege escalation bugs so common, that you should not rely on it to isolate different untrusted users.
- sneak 6y ago
  You can say the same about VMs, to some extent. Containers absolutely are intended to be a security boundary.
  - jedberg 6y ago
    They most certainly are not. That's a common misbelief. Containers are not designed as a security boundary, they just happen to function as one most of the time. VMs on the other hand actually are designed as a security boundary, but even then there are still attacks you can do against other VMs on the same box.
  - beermonster 6y ago
    No they are not https://info.aquasec.com/container-security-book https://info.aquasec.com/container-security-book
    - tekknik 6y ago
      You expect people to read a book to find out your perspective? Do you have cliff notes on why using isolation mode doesn’t provide a security boundary?
      - beermonster 6y ago
        Containers provide resource isolation using a shared kernel but are not intended to be used in hostile multitenancy scenarios. A key feature of OS virtualisation is the strong segmentation boundary between 1. Guests 2. Guests and the hypervisor. For this reason, VMs are seen to provide a stronger security boundary than containers and are used in preference where that aspect is critical owing to environment, multi-tenancy, business context. See also https://searchcloudsecurity.techtarget.com/tip/VMs-vs-containers-Which-is-better-for-security https://searchcloudsecurity.techtarget.com/tip/VMs-vs-contai...
Spivak 6y ago
I think it's easier to say that namespacing is nearly orthogonal to security. Native containers (i.e. containers not running in a VM) are literally just processes running on the host and need to be secured with the same methods you would use on non-namespaced processes. Namespacing does add another layer when used properly but it doesn't replace any of the existing ones.

I agree that containers are something of a security boundary, as is chroot(). Just not as robust a boundary as an actual VM.

imtringued 6y ago

It's not good enough for multi tenant setups. A single malicious customer can potentially steal data from other customers. The docker team also considers security to be a pretty low priority.

jamiesonbecker 6y ago
To say nothing of sidechannel attacks[0] People need to stop looking at containers as a cheap way to get security. They might be a more convenient way to get lots of apps running on a single machine, but they're not very secure. https://ieeexplore.ieee.org/document/7847002 https://ieeexplore.ieee.org/document/7847002
- CodesInChaos 6y ago
  1. I expect people to move towards a VM per pod model, even in private setups. Firecracker claims a memory overhead of 5 MB, and a minimal QEMU setup shouldn't be too bad either. 2. It sounds like this paper is mainly about covert channels not side channels. Covert channels assume cooperation between both sides, so they're only relevant if one of the sides can't communicate trivially (e.g. via network)
  - jamiesonbecker 6y ago
    > vm per pod .. firecracker agreed. AWS gets a lot of flak, but open sourcing firecracker was really great. I'd really prefer to see us move toward vms instead of containers, even if we kept the same k8s abstractions. > .. covert .. thanks for the catch, should have taken more time. Here's a better paper: https://hal.inria.fr/hal-01591808/document https://hal.inria.fr/hal-01591808/document
    - CodesInChaos 6y ago
      > I'd really prefer to see us move toward vms instead of containers, even if we kept the same k8s abstractions 1. For me containers are one of those abstractions, defined by exposing an application controlled userspace. Containers can be implemented by different isolation technologies, from simple chroot/cgroup/namespaces... to VMs. 2. I'd still use chroot&co to partially isolate containers within a pod, while using VMs to strongly isolate pods from each other. This enables features like shared block-devices, unix-domain-sockets and monitoring the processes in an application container from a separate diagnostics container.

CodesInChaos 6y ago

In theory it is a security boundary. But the attack surface is so big, and local privilege escalation bugs so common, that you should not rely on it to isolate different untrusted users.

sneak 6y ago
You can say the same about VMs, to some extent. Containers absolutely are intended to be a security boundary.
- jedberg 6y ago
  They most certainly are not. That's a common misbelief. Containers are not designed as a security boundary, they just happen to function as one most of the time. VMs on the other hand actually are designed as a security boundary, but even then there are still attacks you can do against other VMs on the same box.
- beermonster 6y ago
  No they are not https://info.aquasec.com/container-security-book https://info.aquasec.com/container-security-book
  - tekknik 6y ago
    You expect people to read a book to find out your perspective? Do you have cliff notes on why using isolation mode doesn’t provide a security boundary?
    - beermonster 6y ago
      Containers provide resource isolation using a shared kernel but are not intended to be used in hostile multitenancy scenarios. A key feature of OS virtualisation is the strong segmentation boundary between 1. Guests 2. Guests and the hypervisor. For this reason, VMs are seen to provide a stronger security boundary than containers and are used in preference where that aspect is critical owing to environment, multi-tenancy, business context. See also https://searchcloudsecurity.techtarget.com/tip/VMs-vs-containers-Which-is-better-for-security https://searchcloudsecurity.techtarget.com/tip/VMs-vs-contai...

Spivak 6y ago

I think it's easier to say that namespacing is nearly orthogonal to security. Native containers (i.e. containers not running in a VM) are literally just processes running on the host and need to be secured with the same methods you would use on non-namespaced processes. Namespacing does add another layer when used properly but it doesn't replace any of the existing ones.