51–60 of 76 posts
In what sense is this "OCI compatible"? Do they implement the runtime, image format spec, or both? My understanding of containerization and OCI runtimes is that they're fundamentally different from hardware-level virtualization.
Earlier quoted context omitted.
> containers are not secure, anywhere. Virtual machines are. Can you (or someone else) ELI5 what makes containers insecure? Not a low level Linux or security expert.
I'm sure there's more, but the most obvious is that they share one running kernel. So, one kernel exploit in one container means you now have all the running containers.
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 alwa…
Interesting that nearly half of the backers are Chinese companies.
For comparison: USA: ~30m China: ~80m
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 alwa…
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.
Earlier quoted context omitted.
> 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 ma…
Sounds like you are looking for something closer to LXD or perhaps Rkt.
They don't seem to have written any code yet. [1] So what we have at this point is a marketing website about their ambition and goals? [1] https://github.com/kata-containers/runtimes
The code comes from Intel's Clear Containers and hyper. The interesting bit is that the tech is now part of the openstack foundation, under the name Kata Containers. At Kubecon yesterday, they did a demo, showing a fork bomb taking out a container, but not the host. It actually seems nearly ready to use.
docker run --pids-limit=64Earlier quoted context omitted.
I'm sure there's more, but the most obvious is that they share one running kernel. So, one kernel exploit in one container means you now have all the running containers.
So containers are as vulnerable as the operating system? It seems like if your kernel has been pwned you’re already SOL? Or couldn’t someone in that position just as easily pwn a VM, or run the same exploit on multiple vms? I’m not sure if I’m missing something
Linux containers run a new environment on top of the host's kernel. It's the same kernel in one container as another and the same as in the host. If you manage to break out of the namespace or otherwise exploit the kernel, you're already in some other container's business. Worse, there's a good chance you've exploited the kernel in a way that you can get all the other containers and the host all at once with one exploit.
Earlier quoted context omitted.
Yes – HyperV containers (which Kata is actually inspired by) are much more secure than Linux’ namespaces.
> Kata Containers combines technology from Intel® Clear Containers and Hyper runV but I can't find a mention of Hyper-V anywhere (which doesn't mean there was no inspiration). Maybe you confused Hyper runv and Hyper-V here (the naming certainly doesn't help)?
Earlier quoted context omitted.
Sounds like you are looking for something closer to LXD or perhaps Rkt.
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 t…
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.
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 alwa…
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.