How CoreOS’s rkt Blazes a Secure Trail for appc Containers
It’s difficult for anyone to make an argument in favor of supporting industry standards while simultaneously embracing the notion of a plurality of such standards duking it out against each other in a capitalist market. To be able to pull it off, one’s name usually has to be something like “Google.”
Last year, after CoreOS Inc. launched an effort at establishing a containerization standard called appc or App Container, an alternative with Docker’s libcontainer, there was some open debate (which is common in any open source market) over whether a second standard (or a third, if you still count lxc) was beneficial or harmful to the growth of the concept.
Thursday, as CoreOS declared its competitive rkt (still pronounced “rocket”) container engine good for general release as version 1.0, it officially lifted the remaining veil covering its competitive containerization platform. Its Tectonic orchestration system, which is CoreOS’ commercial incarnation of Google’s Kubernetes, now incorporates a complete rkt container engine. It supports both the Open Container Initiative and appc formats, for containers distributed on its Quay and Quay Enterprise registries, naturally containing CoreOS itself as their Linux kernels.
Co-existence
Now that CoreOS’ platform has officially exited the embryonic stage, just how competitive will it be, and can it be? And will that competition drive the containerization industry forward?
In an interview with The New Stack just prior to rkt 1.0’s release, CoreOS CEO Alex Polvi cited the importance of a single, standard container image format, while at the same time shaving down the scope of standardization to an even barer minimum.
“While we are a hundred percent supportive of standards in general,” said Polvi, “the work that’s been going on in the Open Container Initiative is really focused on the runtime side. What that means is, projects like rkt and Docker could potentially share execution plug-ins that are used for running a container — so there’s a modular, standards-based plug-in interface for how you can execute a container, and tool vendors are able to share that. That’s what OCI’s really focused on.
“What we think is the most important part of a container standard is the actual image format — the end-user format that a company uses to build its container, and then it’s able to take it and run it in rkt or Docker or Amazon EC2 Container Service or whatever, and it works in a similar way.”
Polvi went on to say, however, that he believes the OCI as an organization has been more focused on the development of the universal runtime (another of Docker’s contributions from last June) than the image format itself. By contrast, appc in its current incarnation includes an open image format that contains elements he believes should eventually be included in OCI.
First and foremost, Polvi says, OCI images should include a key feature of appc: cryptographic signatures.
“Docker does have some signature validation capabilities,” the CEO told us, “but it’s not implemented in such a way that an administrator can enforce a policy that says, ‘Only run these images that are allowed.’ And that’s the type of requirement that we think production operations teams need — they’re honestly just basic requirements of any of these sorts of standards. The image format has to have some properties that allow security to be implemented, at even a basic level.”
In a company blog post Thursday, Polvi set out to distinguish rkt as the alternative container platform for the more security-minded organization. He politely chastised the OCI for “creating standards for the container runtime environment, rather than the container image,” and portrayed appc as actually going further toward establishing an open container image format than OCI.
Then Polvi went on to bolster his case for CoreOS’ “security-minded” approach, advocating for a renewal of the goals that gave rise to containerization in the first place: process isolation.
Polvi described a sophisticated, tiered model of process isolation that incorporates the work CoreOS has been doing with Intel. This work enables rkt to support Intel’s Clear Container platform in addition to OCI and appc, leveraging Intel’s VT technology for hosting containers within a lightweight virtualization layer at the hardware level.
“It is about stronger isolation,” he told us. “We’re able to provide virtualization-level isolation on the container, but still keep it a lightweight, quick-to-launch, low-overhead experience that you get with a normal Linux container, combining the best of both worlds.”
Back to Stage One
The original inspiration behind the first lxc containers was process isolation: specifically, giving applications their own, exclusive namespaces. When containers first struck pay dirt, opponents raised an objection that was difficult to counter: Conceivably, a malicious actor that works from within a container could attack the Linux kernel that hosts it, in so doing threatening the stability of all workloads being run by that kernel, virtual or otherwise.
By pairing appc’s signed images with rkt’s tiered virtualization model, CoreOS opens up the possibility that orchestration engines could implement more fine-grained policies for the staged testing and deployment of containers.
In the rkt model, as Polvi described it to us, the first stage enables full hosting privileges for containers downloaded from a registry. This stage may be necessary for certain classes of apps such as system agents, which should not be run with any isolation at all. The next stage up employs the first extra layer of isolation, where namespaces and other Linux resources are rendered exclusive to applications.
This rendering is made possible through rkt’s native support for Security Enhanced Linux (SELinux). By default, rkt runs containers under an SELinux context, rendering them incapable of direct communication with other processes or containers sharing the same kernel, or with the kernel itself.
Then there is the next step up, which CoreOS devised for Clear Containers. Intel devised this format so that workloads could be hosted directly by the underlying hardware of Intel processors. Polvi said that an extremely lightweight OS (implying one more minimalistic than even CoreOS itself) runs as an Intel VT virtual machine, with the help of a low-level hypervisor. Such a container may be orchestrated the same way as any other container on a host, but the fact that it’s not really being hosted by the main Linux kernel is abstracted from the orchestrator.
That may sound like more than sufficient isolation for any potentially dangerous application. But what if an organization intends to deploy a Netflix-like microservices model using containers, where the “application” is a composite of interactive services that transcend clouds and on-premise data centers? Doesn’t that level of isolation work against the microservices model?
“If you’re building a multi-tenant cloud service, like a platform-as-a-service,” responded Alex Polvi, “I would turn on the isolation with the virtualization engine. You don’t have to do that in a bare metal environment, on your own physical servers. But we do have customers that are building multi-tenant cloud services on bare metal that can use the rkt VM-based isolation to get just as good isolation as a virtual machine, but without the overhead of a traditional virtualization.”
Taken in Moderation
On the other hand, he said, for situations where an organization is deconstructing its monolithic applications, and simply needs a more secure, modern platform for running services with the traditional model, Polvi said, “the SELinux approach is probably good enough. The applications that you’re running are somewhat trusted. You’ve got to trust everything you’re running in your own environment; you know they’re not malicious, [unless] a third party is compromising those applications. At which point, SELinux is pretty freakin’ good, in terms of protecting from applications being able to jump outside of the container and do things on the host.”
If a customer is uncertain what to try first, Polvi suggests turning the isolation dial up full-blast and seeing what happens.
“If you can use the benefits of the rigorous security of a full, third-party cloud service provider, but you can do that in your own environment, why not?” he remarked. “Turn it all on. The performance overhead of virtualization, especially on the super-lightweight hypervisor and kernel, is minimal at this point because it’s all hardware-accelerated.”
CoreOS’s value proposition is for organizations that want to go “all-in” — that are willing to take the plunge into a service model using Tectonic and Quay. Contrast that against a competitor that plays toward the “start small, scale up” customer, and CoreOS may finally find itself properly contrasted with the rest of the containerization market without having to start a war to do it.
Docker is a sponsor of The New Stack.
Feature Image: Gemini-Titan 11 rocket, NASA through Wikimedia Commons, public domain.
