CoreOS’s rkt Container is Now Ready for Production Workloads
CoreOS’s container runtime rkt (pronounced “rocket”) is production ready, the company announced Thursday. CoreOS is touting rkt as a more secure alternative to the widely used Docker container environment, thanks to how rkt’s design is based on Unix best practices.
“With rkt now at 1.0, the distributed chain of trust from the application layer all the way down to the hardware is at the fingertips of enterprises that are serious about running their applications in a secure and hyper-scale environment,” said Alex Polvi, CEO of CoreOS, adding that “developers can go for it.”
The company also announced the availability of the accompanying ecosystem support including registry, monitoring and networking.
“CoreOS added a key security element to application containers through its development and enhancement of the rkt container runtime,” said Jay Lyman, research manager with 451 Research.
The production-ready rkt features:
- Stable command-line UX and on-disk format that are backward compatible.
- Advanced security capabilities such as KVM-based container isolation, SELinux support, image signature validation, and basic privilege separation.
- The ability to run existing Docker images and standards-based App Container Images.
Today rkt runs on all modern Linux distributions.
The company also announced rkt monitoring from Sysdig; container registry through its Quay Enterprise product; networking with the Container Networking Interface (CNI) standard and integrations from Project Calico, Weaveworks and Kubernetes.
In August, when CoreOS released version 0.8.0 it announced support for Intel’s VT-x in-silicon virtualization or “Clear Container” technology that launches container images as full KVM virtual machines to provide hardware-assisted security.
Two months ago the company launched a trusted computing platform to run secure containers called Distributed Trusted Computing, which uses Trusted Platform Modules (TPM), a standard for generating processor-based encryption keys.
The Unix Way
Polvi introduced rkt in December 2014 in an incendiary blog post in which he called Docker’s security model “fundamentally flawed.” He’s since softened his stance but remains steadfastly focused on container security.
He says CoreOS built rkt from the ground up to take advantage of Unix best practices. He explains the difference in architecture from Docker in this way:
“The Docker Engine, which is the Docker daemon, that runs on your server as root. It performs a lot of different functions: image uploading, downloading … it has all these pieces of functionality to run a container, which means everything you do has be inside of that application. That thing is running as the most privileged user on your machine. When you type the command ‘Docker run,’ that command is talking to an API in that daemon that’s launching the container on it. So that architecturally creates constraints.
“The rkt model is completely daemon-less. All the commands for downloading an image, verifying it and running the container engine are all modular and you can run them in the normal Unix way, which is you can use your normal system you had before you had containers. It gives you the same effect, but it’s implemented in the best-practice way of doing it.”
At the same time, he says, users don’t have to give up their Docker containers or Docker tools to get the benefits of security with rkt, which can convert Docker images on the fly.
Stability and Security
Gabriel Monroy, chief technology officer of Engine Yard and creator of the platform-as-a-service Deis, which Engine Yard acquired, says that though it has not yet been running rkt for its customers’ containers in production, it has been extensively testing rkt.
“For us, it’s about stability and about security. Security is directly proportional to the amount of code in the code base. As you add code, the risk of vulnerabilities. Rkt is a tight, small code base,” he said.
“Also, the way it handles hashing and signing of the APIs of the container images is much more appealing in that it’s federated, it’s not premised on one company having the root key to the castle,” according to Monroy, who says CoreOS has emphasized a decentralized approach to it.
“One of the things we’ve noticed is that frankly, there’s a lot of instability in the container runtimes that are out there today, Docker notably — things like memory leaks, bugs when systems are coming up and down rapidly you can lose a server and when the server comes back. You can get corruption inside the Docker Engine. There’s a whole class of problems that you only learn about when you’ve been running stuff for many months,” he said.
“One of the challenges we’ve had—we’ve been working with the Docker folks [and] they’re great folks who absolutely want to fix this stuff–the problem that I see is that the code base for the Docker Engine is growing so rapidly, there’s so much new stuff being added to the code base for other things Docker wants to do, that the core job of running a container is kind of an afterthought. If you trace back, a lot of the bugs that we’re finding in production, they’re related to some of this added surface area in the project.”
He said when Kubernetes 1.3, which will integrate with rkt, comes out probably in Q3, his company likely will switch to rkt.
“So rkt to us is doing one thing and doing it really well. It’s just focusing on being a really great container runtime and not, for example, focusing on some of the Docker-specific features around registries, the Docker Hub having sort of preferential treatment inside the code base. …”
Docker is a sponsor of The New Stack.
Feature Image: “Rockets” by Greg Westfall, licensed under CC BY-SA 2.0.
