5 ms·

Starts off saying VMs are like brick and mortar houses and containers are like tents. I agree somewhat but there has been significant progress to sandbox conta

Starts off saying VMs are like brick and mortar houses and containers are like tents. I agree somewhat but there has been significant progress to sandbox containers with the same security we'd expect from a VM. It isn't a ridiculous idea that VMs will one day be antiquated, but probably won't happen for a few more years.

kasey_junk 5y ago
Do you have any links to secure container runtimes that don’t either virtualize or replace all the system calls of the container such that it might as well be virtual?
- adolph 5y ago
  Maybe Singularity? https://sylabs.io/guides/3.5/admin-guide/configfiles.html https://sylabs.io/guides/3.5/admin-guide/configfiles.html
  - kasey_junk 5y ago
    Singularity is likely* less secure than default container runtimes. *not a security person or an expert on singularity but it advertises that it doesn’t do file system or user isolation by default
- deleted 5y ago
  [deleted]
- encryptluks2 5y ago
  First, saying it might as well be virtual is a bit of a misnomer. There are various options, and although they may act like a VM they are significantly faster than machine-based VMs like QEMU: https://kubernetes.io/docs/concepts/policy/pod-security-policy/ https://kubernetes.io/docs/concepts/policy/pod-security-poli... > As of Kubernetes v1.19, you can use the seccompProfile field in the securityContext of Pods or containers to control use of seccomp profiles. If you're looking for a more general abstraction, there is gVisor and others as well.
  - kasey_junk 5y ago
    Again, not an expert but security policies aren't immune from container breakouts right? Which leaves you to either use something like firecracker or gvisor which are either virtualization solutions or the next closest thing in that they intermediate all of your syscalls?
    - encryptluks2 5y ago
      Almost all container breakout concerns rely on running containers as a privileged user: https://stackoverflow.com/questions/53024790/kubernetes-support-for-docker-user-namespace-remapping https://stackoverflow.com/questions/53024790/kubernetes-supp... There is an issue that I've been tracking, and there has been a new PR that will hopefully land soon to implement this in Kubernetes in a simplified manner: https://github.com/kubernetes/enhancements/issues/127 https://github.com/kubernetes/enhancements/issues/127 As for whether security policies prevent breakouts, it really depends on what the exploit is but they can significantly help. The idea of user namespace remapping solves a secondary issue though... if there is a breakout, what user privileges will they have.
- viraptor 5y ago
  We can't answer that question because "secure container runtime" is not a well defined idea. Secure from what, in what way, with what guarantees? Docker is both secure and not depending how you draw the lines.
  - kasey_junk 5y ago
    Sure. I mean as secure as a traditional virtualization environment.
- jb_gericke 5y ago
  Pod security policies and seccomp for call filtering at an OCI level
effie 5y ago
You can't make the Linux kernel isolation of processes as secure as Xen or Firecracker or SEL4 can. Yes, processes can be restricted to subset of syscalls and system resources but Linux is just too big and its attack surface is too big to put it on the same level of confidence as above hypervisors.
mercora 5y ago
i don't think that is necessarily the case but instead i believe in the near future the differences between container sandboxes and virtual machines might be less clear. I imagine CPU and memory namespaces coming implemented on hardware isolation features like VT-d io-mmus and alike thus making virtual machines integrated into some sandboxing feature.

kasey_junk 5y ago

Do you have any links to secure container runtimes that don’t either virtualize or replace all the system calls of the container such that it might as well be virtual?

adolph 5y ago
Maybe Singularity? https://sylabs.io/guides/3.5/admin-guide/configfiles.html https://sylabs.io/guides/3.5/admin-guide/configfiles.html
- kasey_junk 5y ago
  Singularity is likely* less secure than default container runtimes. *not a security person or an expert on singularity but it advertises that it doesn’t do file system or user isolation by default
deleted 5y ago
[deleted]
encryptluks2 5y ago
First, saying it might as well be virtual is a bit of a misnomer. There are various options, and although they may act like a VM they are significantly faster than machine-based VMs like QEMU: https://kubernetes.io/docs/concepts/policy/pod-security-policy/ https://kubernetes.io/docs/concepts/policy/pod-security-poli... > As of Kubernetes v1.19, you can use the seccompProfile field in the securityContext of Pods or containers to control use of seccomp profiles. If you're looking for a more general abstraction, there is gVisor and others as well.
- kasey_junk 5y ago
  Again, not an expert but security policies aren't immune from container breakouts right? Which leaves you to either use something like firecracker or gvisor which are either virtualization solutions or the next closest thing in that they intermediate all of your syscalls?
  - encryptluks2 5y ago
    Almost all container breakout concerns rely on running containers as a privileged user: https://stackoverflow.com/questions/53024790/kubernetes-support-for-docker-user-namespace-remapping https://stackoverflow.com/questions/53024790/kubernetes-supp... There is an issue that I've been tracking, and there has been a new PR that will hopefully land soon to implement this in Kubernetes in a simplified manner: https://github.com/kubernetes/enhancements/issues/127 https://github.com/kubernetes/enhancements/issues/127 As for whether security policies prevent breakouts, it really depends on what the exploit is but they can significantly help. The idea of user namespace remapping solves a secondary issue though... if there is a breakout, what user privileges will they have.
viraptor 5y ago
We can't answer that question because "secure container runtime" is not a well defined idea. Secure from what, in what way, with what guarantees? Docker is both secure and not depending how you draw the lines.
- kasey_junk 5y ago
  Sure. I mean as secure as a traditional virtualization environment.
jb_gericke 5y ago
Pod security policies and seccomp for call filtering at an OCI level

effie 5y ago

You can't make the Linux kernel isolation of processes as secure as Xen or Firecracker or SEL4 can. Yes, processes can be restricted to subset of syscalls and system resources but Linux is just too big and its attack surface is too big to put it on the same level of confidence as above hypervisors.

mercora 5y ago

i don't think that is necessarily the case but instead i believe in the near future the differences between container sandboxes and virtual machines might be less clear. I imagine CPU and memory namespaces coming implemented on hardware isolation features like VT-d io-mmus and alike thus making virtual machines integrated into some sandboxing feature.