
Kata Containers – The speed of containers, the security of VMs - bharatkhatri14
https://katacontainers.io
======
jeremyjh
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](https://github.com/kata-
containers/runtimes)

~~~
paulfurtado
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.

~~~
redtuesday
Can't you just combat fork bombs with e.g

    
    
      docker run --pids-limit=64

~~~
paulfurtado
Yes, there are several ways to combat fork bombs (ulimits or pid namespaces).
This was purely for the sake of the live demo that required a kernel crash
example, there are certainly other ways to combat it.

------
reacharavindh
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?

~~~
odiroot
Interesting that nearly half of the backers are Chinese companies.

~~~
supermatt
Not when you consider that half of all companies are Chinese companies.

For comparison: USA: ~30m China: ~80m

------
perlgeek
One thing that isn't mentioned on front page at least is the management
aspect.

Docker became popular because it was pretty easy to use, and to publish and
reuse existing containers. Whatever competes with it only stands a chance if
it can either reuse the existing container ecosystem, or offer something
roughly as good.

~~~
paulfurtado
Sat through the talk at kubecon yesterday - an important goal of theirs is to
not compete with the docker. They said it was compatible with docker,
containerd, and cri-o. I believe with docker, it sits at the runc level, so to
the end user, you're using docker in the standard fashion, but the underlying
isolation mechanism is different. They also said it can be chosen per
container so different containers on the same host can use different isolation
mechanisms

~~~
perlgeek
That makes a lot of sense, and probably the road that makes adoption easiest.
Thanks!

------
mnd999
The British Indian Ocean territory really is becoming a tech hub.

~~~
oblio
I'm not sure I get the connection. Also:
[https://en.m.wikipedia.org/wiki/Depopulation_of_Chagossians_...](https://en.m.wikipedia.org/wiki/Depopulation_of_Chagossians_from_the_Chagos_Archipelago)

~~~
CapacitorSet
>I'm not sure I get the connection.

.io is the TLD for the British Indian Ocean Territory, technically speaking.

------
e_d_e_v
How is this better than using rkt with an lkvm stage1[1], which also uses the
work done by the Clear Containers team? It looks like Kata packages QEMU as
well, which seems a bit overkill.

[1][https://coreos.com/rkt/docs/latest/running-kvm-
stage1.html](https://coreos.com/rkt/docs/latest/running-kvm-stage1.html)

~~~
bonzini
> a bit overkill

They also said the same about Xen, that a special purpose microkernel was a
better choice than Linux as a hypervisor...

~~~
e_d_e_v
Right, in many cases, small is beautiful! I think that's what contributed so
heavily to the massive success of the Xen platform. Is that what you mean?

~~~
bonzini
Then why does Kata Containers use KVM?

Xen was successful because it was innovative, and because it worked around the
fact that x86 was not virtualizable at the time. But after ten years of
healthy competition, the only reason to prefer Xen to KVM would be things like
QubesOS.

------
chungy
It's kind of interesting that it's only in the Linux world that containers
cannot be thought of as isolated or secure. Seeing it from a jails and zones
perspective, rather sad, actually :)

~~~
jchw
FreeBSD jails are known to not be silver bullets. I've heard many instances of
breaking out of a FreeBSD jail.

Generally, treating any OS-level technology as a silver bullet is a huge
mistake. Any serious developer would make multiple levels of security that
_should_ be sound.

~~~
X86BSD
This is the most blatant and clearly incorrect... FUD?..lie?... I have ever
heard to date about jails.

Jails are secure. As are SmartOS zones. Whoever you heard that there are “many
instances of breaking out of a jail” from is full of sh47. And you would be
wise to never listen to them ever again. No really, EVER.

And no, breaking the ps4 was not a jail exploit. The attacker already had
elevated privileges. So you would be sunk no matter what.

~~~
jchw
Sheesh, no need to get so emotional about it. I said instances of breaking
out, not instances of jail exploits. I don't know of any jail-specific
exploits.

But when we say "elevated privileges" are we talking root inside of a jail?
Because if that breaks jails, then a large class of Docker exploits also
wouldn't classify as 'exploits' under that criteria. One of the biggest
problems with Linux namespaces is the band-aid put over root, via
capabilities.

As far as I know, though, the PS4 exploit was more Sony's fault. IIRC, they
broke out of the jail by exploiting custom syscalls not in stock FreeBSD. Bugs
in syscalls in FreeBSD aren't unheard of though, even if less commonly found
than Linux.

My entire point is that good security implies not treating any solution as a
panacea, lest you find yourself in a digital Titanic scenario. Multiple layers
of solid security beats one layer of solid security.

~~~
chatmasta
> Bugs in syscalls in FreeBSD aren't unheard of though, even if less commonly
> found than Linux.

Dangerous assumption.

More likely, there are fewer people looking for vulnerabilities in BSD than in
Linux.

~~~
jchw
Well, I did say

>less commonly found

rather than less common. Impossible to know with 100% certainty what's
literally less common.

If I had to guess, I'd guess FreeBSD had less bugs in general, just because
the surface is generally smaller, and the system is more homogeneous.

------
tripue
Another alternative is using hyper container

~~~
tpetry
This is a combined work of the people behind Intel Clear containers and Hyper
containers.

------
acobster
> _It is designed to be architecture agnostic, run on multiple hypervisors and
> be compatible with the OCI specification for Docker containers_

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.

~~~
bergwolf
Both. The hardware virtualization related settings are configured out side of
OCI spec but the runtime accept OCI spec and plays with it accordingly. As for
image format, Kata runs unchanged docker images.

------
jeshwanth
Whats the difference between unikernels and kata containers?

~~~
jchw
Different approaches to isolation. A kata container is using Clear Linux to
load a feature-complete Linux kernel into tiny VMs (disclaimer: I do not know
exactly how it's different from any other VM,) a unikernel is a small bare-
metal "library" that gives you minimal OS-like functions to put in a
hypervisor to run your application. Unikernels are still more minimal, I'd
guess.

~~~
ams6110
Here's a recent paper about the unikernel approach

[http://cnp.neclab.eu/projects/lightvm/lightvm.pdf](http://cnp.neclab.eu/projects/lightvm/lightvm.pdf)

