rkt 1.3.0: Tighter security; easier container debugging, development, and integration [feedly]

----
rkt 1.3.0: Tighter security; easier container debugging, development, and integration
// CoreOS Blog

The latest edition of rkt, the modern, secure container engine required to assemble and secure today's infrastructure at scale, introduces a number of updates to highlight. rkt version 1.3.0 improves handling of errors within app containers, tightens security for rkt's modular stage1 images, and provides a more compatible handling of volumes when executing Docker container images rather than rkt's native ACI image format. This release further develops the essential support for rkt as a component of the Kubernetes cluster orchestrator. Version 1.3.0 continues to advance rkt as a key piece of the CoreOS Tectonic enterprise Kubernetes distribution, and as part of the broader CoreOS mission to secure the infrastructure that powers the Internet.

rkt and Kubernetes: Packaging and execution

Since version 1.0 in February, rkt has become an essential part of the Kubernetes deployment story on CoreOS, easing the spin-up of Kubernetes clusters while illustrating the benefits of rkt's modular architecture. Using a specialized stage1 image, rkt controls the download, cryptographic verification, and execution of the kubelet node manager on each CoreOS cluster member. This decouples the cluster orchestration software layer both from the underlying operating system and the containerized application layer, allowing easier and more frequent updates to all of the components, increasing agility and security for DevOps teams.

We've also been working to make rkt a first-class container runtime in Kubernetes, and recent weeks have seen great progress on this front. At this writing, roughly 85% of the end-to-end tests in Kubernetes pass with rkt executing containers on cluster nodes. It is possible to run many cluster jobs with the rkt engine today, and soon, with complete test coverage and feature parity, Kubernetes will have an interchangeable, modular choice between container runtimes.

Easier container debugging, development, and integration

The recording and propagation of errors within containers varies between different stage1 implementations, so we simplified it in this release. In earlier rkt releases, the default stage1 could produce scenarios where the application pod exited with a non-zero, error status, while rkt itself exited with a zero status. This posed problems for build or CI pipelines relying on rkt exit status codes to track application conditions. In version 1.3.0, the error codes produced by applications running in containers under the default stage1 are now properly communicated to the operating system. Note that alternate stage1 images, like the LKVM hypervisor provider, will need to incorporate their own handling of in-container errors.

Stage1 images are now verified with their signatures by default, like other container images, making the modular stage1 interface more secure. Another security change allows development workflows to use a new --insecure-options=pubkey option to temporarily allow downloading insecure public keys for testing purposes.

With version 1.3.0, improvements are made to how multiple rkt processes behave when fetching container images concurrently. A new flag to set the pod hostname when invoking rkt allows for dynamic naming schemes in similar multi-container and multi-pod scenarios. Another new benefit to ACI builders is support for user and group names in the image manifest, rather than only UID/GID integers.

Docker image compatibility refinements

For those using rkt to execute Docker-built images in a secure, modular container runtime environment, rkt now implements the Docker volume semantics more compatibly. Files from the container image are copied to the volume path in the container, unless a host volume is mounted over that path. This behavior only applies when running Docker container images, and does not change rkt's handling of volumes and mounts in ACIs.

rkt packages for other Linux distributions

The 1.3.0 release also improves support for rkt on other distributions, making Fedora's SELinux rules play more nicely with rkt. While overlayfs support with SELinux on Fedora continues to be a work in progress, with these changes, in Fedora 24 and Rawhide, rkt generates per-instance SELinux contexts, preventing processes in a container from interacting with any processes or files in any other context.

The effort to package rkt for Debian has made significant progress as well, and most of the dependencies have been approved. rkt manual pages have been added as part of the packaging requirements. This work is ongoing, and we hope to have it completed in the very near future, making rkt more easily available to Debian and Ubuntu users. A big thanks to Dmitry Smirnov for spearheading the work to package rkt for Debian.

For more information and all the dev-level details of the rkt 1.3.0 release, check the release notes.

Take off with rkt!

We encourage you to join the community to improve and influence rkt, a central component of the CoreOS and Tectonic platforms. Get involved on the rkt-dev mailing list or on the #rkt-dev Freenode IRC channel, by filing GitHub issues, or by contributing code and fixes to the project.

Work at CoreOS

Interested in helping CoreOS secure the Internet? Join us! We're hiring engineers in New York, Berlin, and San Francisco.

----

Shared via my feedly reader

Sent from my iPhone