Recently, CoreOS, the creators of a streamlined Linux distribution with running containers in mind, announced the 1.0 release of Rocket (rkt), their home grown container runtime environment. CoreOS was initially released in October of 2013, and has seen a massive adoption rate in a little over two years. The fact that this company and distribution is so young makes their venture into the container space even more remarkable.
On December 1, 2014, CoreOS announced they were moving further into the container game with their own engine and container spec, designed with a very important feature in mind, Security? Why Security? CoreOS saw the potential for containers in the enterprise, and got ahead of the game by designing their runtime environment with security in mind, which is a must for many organizations to adopt a new technology.
Now, little more than a year later, thanks to over 100 contributors, Rocket 1.0 is here and ready to get serious. In addition to the creation of Rocket, CoreOS has also been a key player in determining a standard for containers, which makes sense. Containers can lose some of their inherent values and benefits if an organization is locked into a specific environment. The App Container (appc) specification seeks to do this, at the container image level to provide portability for containers, a key part of the container value proposition. The appc standard format, App Container Image, or ACI is often confused with OCI, or the Open Container Initiative. There is a key difference between the two of these. ACI focuses on the containers themselves, and ensuring they will run in multiple runtime environments in a standardized form. While OCI is focused on the runtime environment, not the container images themselves. It is easy to see how these two standards may work together in the future, but it is also important to remember they are two distinctive entities.
Rocket allows organizations to run already existing Docker containers, as well as appc images. In addition to running on CoreOS, of course, Rocket is ready to run on many popular Linux distributions such as Ubuntu, making it even easier for organizations to adopt. Rocket also boasts a large partner ecosystem, for management, monitorring, clustering and more of containers. Some of the most notable are Kubernetes and Intel, allowing for additional usability features and functionality of the Rocket runtime environment.
One interesting security aspect of Rocket is the use of Intel’s KVM based Clear Containers. Clear containers allow isolation of a rocket environment, ensuring containers are restricted to their virtual machine. This the secure isolation of standard virtual machines with development ease and portability of containers. On a similar vein, rkt fly allows the execution of software which requires full host access, while again bringing the benefits of containers to an environment. Modular isolation has been an interesting aspect to the development of Rocket, with CoreOS looking at areas that containers previously did not investigate. By developing Rocket with Unix best practices in mind, CoreOS takes a different approach to containers, which is one of the reasons the Rocket environment has taken off so fast.
Alex Polvi, the founder and CEO of CoreOS, seems to be executing on the mission of CoreOS to “improve the security and reliability of the internet”. The world of IT is speeding up and so is the rate of attack on vulnerabilities and exposed resources. Having securing in mind at the onset means that IT organizations can be secure and agile in the same step, which has been a fundamental flaw in much of Ops and Dev teams for decades.
So, as this release sets the starting point for the future of Rocket and much more, we begin the journey in what Alex Polvi calls “filling the white space” to building out a true platform approach to secure container infrastructure. What’s equally important is that it’s being done with the velocity of a growing and avid community behind it. Now is the time put Rocket, CoreOS, Kubernetes, and all of these exciting components to the test in our own infrastructure.