----
The Security-minded Container Engine by CoreOS: rkt Hits 1.0
// CoreOS Blog
Today is a big day for CoreOS rkt, the container engine designed for security, efficiency and composability. With the mission to be the most secure and composable container engine, rkt was born in 2014 at a time when interest in cloud-native computing and containers began to take off. Since then, the need for a secure, production-ready container runtime has continued to spread.
Today CoreOS has graduated rkt to version 1.0.
We've worked hard to make rkt fit readily and flexibly into real-world architectures, while enabling the best security practices, and the community's input and support has been instrumental. After 15 months of continuous development, rkt has incorporated more than 3,000 commits from more than 100 contributors.
A major rkt milestone
To lift off with rkt right away, check out this introductory blog post and screencast.
With rkt 1.0, we are introducing:
- Stable interfaces and on-disk format: The command line UX and on-disk format are now considered stable and safe to develop against. Any changes to these interfaces will be backwards compatible and subject to formal deprecation.
- Advanced security capabilities: With features such as KVM-based container isolation, SELinux support, TPM integration, image signature validation, and privilege separation, rkt is the container engine of choice for the security-minded.
- Run existing Docker Images and standards-based App Container Images: While rkt is committed to standards, it remains compatible with the Docker image format. This means you can build with Docker, run with rkt. Additionally, CoreOS will support the growing ecosystem of tools based around the App Container Image format.
- A robust community: rkt's ecosystem continues to grow into a strong community of developers and operators that are committed to providing a secure, composable, standards-based container engine. Today rkt is ready to run on Arch, CoreOS, Ubuntu, Fedora, NixOS and other Linux platforms, and in use by a growing number of projects and products.
Why rkt? A brief history
As we celebrate this important milestone, it's useful to reflect on the history of the rkt project and why CoreOS is continuing to invest in it. As we described in the initial rkt announcement, we started building rkt to create a container engine that takes security, composability, and standards seriously.
- Secure: rkt includes privilege separation for operations that should not run as root, image signature validation by default, and other advanced features for the security-minded.
- Composable: rkt does not require a long-running background daemon, and works with existing init systems such as systemd or upstart.
- Standards-based: A "standard container" is only possible if multiple tools share a well-specified standard for how users build and package container images. rkt is committed to supporting and providing backwards compatibility for container standards.
Security-minded capabilities
rkt is built from the ground up to be ready for security-focused environments. Many of these principles weren't invented at CoreOS — instead, we applied common, everyday best practices that have been largely overlooked in the container industry so far.
Architected for best practices
rkt strives to embody the Unix "tools" philosophy and learn from decades of best practices in architecture and security. This includes image signature validation by default, and privilege separation between different tasks, like image discovery and retrieval — unprivileged operations in rkt — versus container execution, requiring root access. rkt's daemonless model means it can integrate easily with standard init systems, such as systemd and upstart, or with cluster orchestration systems, like Nomad and Kubernetes.
Pluggable isolation, including KVM-based "Clear Containers"
Modular isolation means that rkt supports a variety of techniques for running containers. While software-isolated Linux cgroups containers are the default, advanced solutions like Intel's KVM-based "Clear Containers" or host-level rkt fly provide selectable degrees of container confinement.
Intel Clear Containers
With Intel's Clear Containers-based stage1, rkt is able to execute standard ACIs with CPU-enforced isolation. This balances the best of both worlds: application-focused packaging and deployment efficiencies, with the explicit hardware-guaranteed isolation of a virtual machine.
rkt fly
With the fly stage1 isolation environment, rkt executes a standard container image with full access to the host environment. This means you can run specially-privileged software, such as system management agents that need full host access, while maintaining image signature and deployment policies. Using rkt with fly retains the packaging and distribution benefits of app containers for even the lowest-level system programs.
Automatic SELinux
On an SELinux-enabled kernel, rkt automatically configures the appropriate SELinux tags to execute each pod in mandatory isolation from other containers and host processes. This means that even if a container is compromised, it will be unable to gain access to other containers or to the host.
TPM integration
rkt harnesses the ubiquitous Trusted Platform Module (TPM) on modern server systems for tamper-proof logging of pod activity, a major innovation that advances the state of the art of container security. TPM integration is a key component enabling a new class of infrastructure we call Distributed Trusted Computing.
appc and OCI
The rkt community is committed to supporting open standards. rkt started as an implementation of the specifications developed in the App Container (appc) project. In mid-2015, a new body emerged, the Open Container Initiative (OCI), with the goal of creating more standards around application containers. At first glance, appc and the OCI appear to be similar efforts. So much so, it can be confusing to understand where they overlap and where there is room for cooperation.
We believe the most important aspect of any container standard is a developer-packaged, easily-distributable image format. For appc this format is the App Container Image (ACI) and Docker exclusively uses its own Docker Image format. Despite the importance of a shared standard, after six months of effort the Open Container Initiative (OCI) body has yet to decide whether it should or should not develop and standardize an image format. Today, the primary focus of the OCI community is creating standards for the container runtime environment, rather than the container image. Specs for container runtime features are also a worthy discussion, but we think there is a more urgent need – and a more open, industry-wide upside – for a standard container image specification. In short, OCI and appc are related, but not mutually exclusive. There is plenty of room for them to cooperate and cross-pollinate now and in the future.
Overall, our goal is to ensure developers can build and sign app container images in a standard format, with a choice of tools, and deploy them in a variety of runtimes. That's why we continue to work on the App Container specification and associated image format alongside the appc community. Our commitment to compatibility and choice means rkt supports applications packaged in either ACIs, or Docker's classic images. You can learn more about App Container in rkt's introduction to the appc image format.
Production containers need a robust ecosystem
We have worked closely with the community to get rkt to 1.0, and today we celebrate alongside those who have helped make rkt the most secure container runtime and fostered a burgeoning ecosystem. Today it is possible to launch rkt as a VM thanks to work with Intel, monitor rkt in production with Sysdig, integrate rkt networking with Project Calico, store rkt containers with Quay, and more. These rapid ramps to rkt deployment showcase the growing community around rkt and appc, and the power of open standards to spur innovation among partners.
Check out some of the projects and stories rkt has sparked in the ecosystem:
Apcera
Apcera created Kurma, another container runtime based on the App Container spec.
"We applaud the 1.0 release of rkt because it is an important milestone for container runtime standards. rkt is the first 1.0 implementation of App Container (appc) spec that is production-ready," said Ken Robertson, lead architect with Apcera. "Apcera continues to believe in the value of appc and container standards as seen by continued investment in our implementation, Kurma."
BlaBlaCar
BlaBlaCar, a trusted ridesharing provider founded in 2006, has been an early proponent of the capabilities of rkt and has gone all-in on containers.
"Since rkt development began, we have been impressed by the stability and the flexibility of rkt even in very early versions," said Simon Lallemand, system engineer at BlaBlaCar. "We are migrating all our services to rkt and CoreOS. As of today, 90 percent of our product already runs on this platform."
Deis (Engine Yard)
"The rkt container runtime fills a big need in the market," said Gabriel Monroy, CTO of Deis. "As we put containers into production on behalf of our customers, the more we value a container runtime that does one thing really well. The CoreOS team has proven they can deliver distributed systems building blocks that are stable and secure — and rkt is no exception."
Giant Swarm
"We are big fans of rkt and excited to celebrate the rkt 1.0 launch," said Timo Derstappen, founder and CTO of Giant Swarm. "CoreOS is leading the security conversation, not only with rkt, but with the CoreOS suite of products. As the industry builds out next generation infrastructure and moves towards microservices architecture, rkt is another step in the right direction."
HashiCorp
HashiCorp has added support for rkt in Nomad.
"I'm happy to see that rkt is now 1.0," said Mitchell Hashimoto, founder of HashiCorp. "We support rkt in Nomad alongside our other drivers, so companies can easily deploy rkt containers. Nomad makes it easy to deploy one to thousands of rkt containers."
Huawei
Huawei has contributed to rkt in multiple ways, both with a container registry and by providing ARM support.
"Congratulations to CoreOS for the official release of the container runtime, rkt v1.0. This is another milestone in the container technology world," said Dr. Ying Xiong, chief architect of PaaS, Huawei. "Together with other technologies, rkt is part of our overall container technology stack, and this is important to our customers and partners."
Intel
"Container based environments such as rkt offer incredible portability for data center workloads. Our work with CoreOS has optimized rkt to take full advantage of Intel platform technologies to deliver improved workload isolation and hardware based security capability, critical capabilities for broad market deployments. We look forward to working with CoreOS towards adoption of rkt based solutions in the marketplace," said Das Kamhout, principal engineer and Software Defined Infrastructure architect, Intel Corporation.
Kubernetes
"Integrating rkt embodies Kubernetes' principles of openness and choice, and it is great to see it reach the 1.0 milestone," said Dawn Chen, core contributor to Kubernetes. "We are excited to work with CoreOS and the rkt community to ensure a first-class integration in Kubernetes and give users a choice to use the image format that best meets their needs."
Project Calico (Metaswitch Networks)
Today Project Calico announced their Container Network Interface (CNI) networking plugin for rkt 1.0:
"We have believed in supporting the App Container spec and the corresponding CNI spec from the beginning to ensure the broadest possible set of options for container users to easily plug in their containers and have the networking they need for success," said Andy Randall, evangelist and general manager of Project Calico at Metaswitch Networks. "Project Calico is proud to enable the development community to securely deploy container-based applications, thanks to the combination of rkt's enhanced security measures and Calico's fine-grained policy enforcement."
Sysdig
Today Sysdig is announcing real-time monitoring and troubleshooting of rkt containers in both Sysdig Cloud and sysdig open source. As the only container-native monitoring solution, Sysdig's new functionality gives you the ability to visually understand the performance of your physical infrastructure, containers, and even the applications running within rkt.
"The rkt 1.0 milestone is a big achievement for the container community and is helping provide built-in security for application development and deployment," said Loris Degioanni, CEO of Sysdig. "To help the rkt community bring their deployments into production, Sysdig now provides rkt monitoring, alerting, and troubleshooting in Sysdig Cloud and Sysdig open source."
systemd
"I believe in the rkt model," said Lennart Poettering, systemd lead developer. "Integrating container and service management, so that there's a 1:1 mapping between containers and host services is an excellent idea. Resource management, introspection, life-cycle management of containers and services – all that tightly integrated with the OS; that's how a container manager should be designed."
Get started with rkt on CoreOS, Ubuntu, or Fedora
Get started with rkt in three minutes. Jump in to the latest rkt docs or sample systemd units.
Please join our community sync on February 10 at 9 a.m. PT to take part in the community discussion.
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment