6 ms·

Impressive backing by the big name companies. The idea of treating containers as secure and isolated as VMs is enticing for non-ephemeral services. Are these s

Impressive backing by the big name companies. The idea of treating containers as secure and isolated as VMs is enticing for non-ephemeral services. Are these strictly tuned to exploit intel Hardware features or would they consider supporting the equivalent features in say AMD? On the other hand, isn't this the realm of mainline distributions like RHEL, Debian and the like? To support such isolation facilities. I always thought clear Linux was a Intel playground for proof-of-concept which will eventually be up streamed to major Linux distributions.Is it not true? I guess my question is why a separate project like this, instead of RedHat Enterprise Containers or Debian containers?

FooBarWidget 9y ago
> The idea of treating containers as secure and isolated as VMs is enticing for non-ephemeral services Are you saying that security and isolation is not enticing for ephemeral services? I know that an ephemeral container is reset after a restart but I think that it's a bit naive to think that that is a good enough replacement for true isolation.
- reacharavindh 9y ago
  > Are you saying that security and isolation is not enticing for ephemeral services? Didn't mean to imply the reverse logic of my statement. I believe Linux Containers (and hence Docker) depend only on Kernel namespaces to provide isolation. In my admittedly naive eyes, they were not good enough/mature to replace my KVM VMs yet. Too much to trade off for little convenience/performance. However, if Linux containers matured up and offered the same isolation facilities that something like KVM does, then I can think about switching to them in future, and enjoy the performance boost. >I know that an ephemeral container is reset after a restart but I think that it's a bit naive to think that that is a good enough replacement for true isolation. If I'm looking to run an application for which I care about solid isolation of resources, I'd spend my time running it as VM. But, if I'm running a one-time script that chews some data and I don't care much about it bothering other workloads in the system or other workloads bothering it, then I'd fall back on the isolation facilities offered by namespaces by using Containers. Nothing wrong with that. Security view on these is another argument. If I can't afford the application escalating it's view and looking into other workloads in that system, I just wouldn't run them in Containers today.
  - devonkim 9y ago
    Sounds like you are looking for something closer to LXD or perhaps Rkt.
    - reacharavindh 9y ago
      But, AFAIK, LXD and RKt are similar to Docker as a container runtime though. They all share the host kernel, and if one container is hosed/tainted, your host kernel becomes the attack vector. If I read correctly, hypercontainer/kata containers lets you bring your own kernel for your containers and isolates it from the host using intel hardware features(same ones that KVM leverages). That's where it gets interesting to me.
      - bonzini 9y ago
        Kata Containers uses KVM; QEMU, which is the userspace KVM client, is configured so that it looks like you are running on a container. However, what you get is indeed a virtual machine. It is simply impossible for "real" containers to provide the same isolation as virtual machine, simply because the attack surface is that of the shared kernel; a hypervisor presents a much more constrained interface to a VM than the full kernel, even if you add QEMU to the mix.
        pstuart 9y ago
        Silly question: if the KVM is using para-virtualized drivers and there is a vulnerability in same, then the host kernel would still be vulnerable?
        bonzini 9y ago
        Many of KVM's paravirtualized drivers run in QEMU, and in turn that is usually running heavily confined, for example using SELinux. So it's true that, as in the famous Theo de Raadt rant, virtualization overall adds to the attack surface compared to containers. But it would also be stupid to ignore that it also introduces very important bottlenecks: to get to the hypervisor, you have to break KVM which is only ~60000 lines of code; getting remote code execution in QEMU might be easier, but then you also have to break the host kernel from a process that has access to almost nothing on the system. There is also vhost, which is implementing PV drivers in the host kernel. This however is also a small amount of code, and it is generally used only for networking and AF_VSOCK sockets.
odiroot 9y ago
Interesting that nearly half of the backers are Chinese companies.
- supermatt 9y ago
  Not when you consider that half of all companies are Chinese companies. For comparison: USA: ~30m China: ~80m
perlgeek 9y ago
> On the other hand, isn't this the realm of mainline distributions like RHEL, Debian and the like? At least Debian doesn't develop isolation solutions on its own; it tends to package software that's already out there. And if it's popular enough, it might be integrated fairly tightly into the distribution.
hacknat 9y ago
At the Kubecon demo yesterday they cracked a joke about promising to support more architectures. They seem to sincerely want to, which is why they donated the project to OpenStack. Honestly it seems really cool, the spin up time is damn impressive.
mugsie 9y ago
Separate projects like this is how a lot of these "RHEL Enterprise $FOO" are actually made. RedHat / Suse / Ubuntu / $Vendor take the upstream project, tidy it a bit, package it, get it integrated in their ecosystem, and add an easy installer. Having it in a vendor neutral foundation means that all the vendors can colaborate, and not have one group with a massive advantage or complete control over a roadmap.
- bonzini 9y ago
  There are hundreds of engineers working on RHEL (disclaimer, that includes me), so it's not as simple as you put it...
  - mugsie 9y ago
    No, it is not - I over simplified the process a lot. (/me used to work in a vendor, and in a different large Linux distro :) ) I didn't mean to undermine the work that goes into turning a project like this, OpenStack, Kubernetes, Cloud Foundry etc into a real product that users can download and install on random hardware in random configurations, and get a working system - it is a ton of work, and is massively important for getting actual users to install what are very complex distributed systems.
peterwwillis 9y ago
> Impressive backing by the big name companies. From someone who works at big name companies: this should not impress anyone. Big companies love slapping their name on things that give them "innovation" credibility. It's like Pepsi sponsoring the X Games. > why a separate project like this This is an OpenStack project, so it's not vendor-specific. It's also supposed to be a new "standard container", which I highly doubt will happen because they're just slapping together two other projects.

FooBarWidget 9y ago

> The idea of treating containers as secure and isolated as VMs is enticing for non-ephemeral services Are you saying that security and isolation is not enticing for ephemeral services? I know that an ephemeral container is reset after a restart but I think that it's a bit naive to think that that is a good enough replacement for true isolation.

reacharavindh 9y ago
> Are you saying that security and isolation is not enticing for ephemeral services? Didn't mean to imply the reverse logic of my statement. I believe Linux Containers (and hence Docker) depend only on Kernel namespaces to provide isolation. In my admittedly naive eyes, they were not good enough/mature to replace my KVM VMs yet. Too much to trade off for little convenience/performance. However, if Linux containers matured up and offered the same isolation facilities that something like KVM does, then I can think about switching to them in future, and enjoy the performance boost. >I know that an ephemeral container is reset after a restart but I think that it's a bit naive to think that that is a good enough replacement for true isolation. If I'm looking to run an application for which I care about solid isolation of resources, I'd spend my time running it as VM. But, if I'm running a one-time script that chews some data and I don't care much about it bothering other workloads in the system or other workloads bothering it, then I'd fall back on the isolation facilities offered by namespaces by using Containers. Nothing wrong with that. Security view on these is another argument. If I can't afford the application escalating it's view and looking into other workloads in that system, I just wouldn't run them in Containers today.
- devonkim 9y ago
  Sounds like you are looking for something closer to LXD or perhaps Rkt.
  - reacharavindh 9y ago
    But, AFAIK, LXD and RKt are similar to Docker as a container runtime though. They all share the host kernel, and if one container is hosed/tainted, your host kernel becomes the attack vector. If I read correctly, hypercontainer/kata containers lets you bring your own kernel for your containers and isolates it from the host using intel hardware features(same ones that KVM leverages). That's where it gets interesting to me.
    - bonzini 9y ago
      Kata Containers uses KVM; QEMU, which is the userspace KVM client, is configured so that it looks like you are running on a container. However, what you get is indeed a virtual machine. It is simply impossible for "real" containers to provide the same isolation as virtual machine, simply because the attack surface is that of the shared kernel; a hypervisor presents a much more constrained interface to a VM than the full kernel, even if you add QEMU to the mix.
      - pstuart 9y ago
        Silly question: if the KVM is using para-virtualized drivers and there is a vulnerability in same, then the host kernel would still be vulnerable?
        bonzini 9y ago
        Many of KVM's paravirtualized drivers run in QEMU, and in turn that is usually running heavily confined, for example using SELinux. So it's true that, as in the famous Theo de Raadt rant, virtualization overall adds to the attack surface compared to containers. But it would also be stupid to ignore that it also introduces very important bottlenecks: to get to the hypervisor, you have to break KVM which is only ~60000 lines of code; getting remote code execution in QEMU might be easier, but then you also have to break the host kernel from a process that has access to almost nothing on the system. There is also vhost, which is implementing PV drivers in the host kernel. This however is also a small amount of code, and it is generally used only for networking and AF_VSOCK sockets.

odiroot 9y ago

Interesting that nearly half of the backers are Chinese companies.

supermatt 9y ago
Not when you consider that half of all companies are Chinese companies. For comparison: USA: ~30m China: ~80m

perlgeek 9y ago

> On the other hand, isn't this the realm of mainline distributions like RHEL, Debian and the like? At least Debian doesn't develop isolation solutions on its own; it tends to package software that's already out there. And if it's popular enough, it might be integrated fairly tightly into the distribution.

hacknat 9y ago

At the Kubecon demo yesterday they cracked a joke about promising to support more architectures. They seem to sincerely want to, which is why they donated the project to OpenStack. Honestly it seems really cool, the spin up time is damn impressive.

mugsie 9y ago

Separate projects like this is how a lot of these "RHEL Enterprise $FOO" are actually made. RedHat / Suse / Ubuntu / $Vendor take the upstream project, tidy it a bit, package it, get it integrated in their ecosystem, and add an easy installer. Having it in a vendor neutral foundation means that all the vendors can colaborate, and not have one group with a massive advantage or complete control over a roadmap.

bonzini 9y ago
There are hundreds of engineers working on RHEL (disclaimer, that includes me), so it's not as simple as you put it...
- mugsie 9y ago
  No, it is not - I over simplified the process a lot. (/me used to work in a vendor, and in a different large Linux distro :) ) I didn't mean to undermine the work that goes into turning a project like this, OpenStack, Kubernetes, Cloud Foundry etc into a real product that users can download and install on random hardware in random configurations, and get a working system - it is a ton of work, and is massively important for getting actual users to install what are very complex distributed systems.

peterwwillis 9y ago

> Impressive backing by the big name companies. From someone who works at big name companies: this should not impress anyone. Big companies love slapping their name on things that give them "innovation" credibility. It's like Pepsi sponsoring the X Games. > why a separate project like this This is an OpenStack project, so it's not vendor-specific. It's also supposed to be a new "standard container", which I highly doubt will happen because they're just slapping together two other projects.