We attempt to ship new versions of Red Hat Enteprise Linux Atomic Host (RHELAH) every six weeks. I am in charge of the Docker portion of each release. I also lead the team developing the atomic command. As a major component of the RHELAH release, we want to include the most recent Docker release possible to our users.

However, just because Docker releases a new version does not mean this instantly gets into the RHEL release. We need to allow our QE team time for testing, and to make sure it is “Enterprise Ready.” Towards the end of the most recent six week period Docker released an updated Docker 1.6.1 package with a series of CVEs.

Naturally, Red Hat’s Security Response Team (SRT) analysed these CVEs to see if we needed to hold up the release to include Docker 1.6.1. After careful analysis, SRT decided that the potential threat posed by these CVEs was not a real risk to users who deploy containers responsibly.

Trevor Jay, from Red Hat Security, states:

Technically speaking, these don’t cross any trust boundaries. Docker images are root-run software. They can drop or restrict permissions and capabilities so that you’re protected should they become compromised just like any other software that starts with elevated privileges, but you are inherently trusting the image itself to be well-written (to take advantage of the safeties we provide) and non-malicious.

This is all about trusting the application you install on your system. Sometimes I worry people have the opinion that any piece of software I install, as long as it is in a container I am safe. I believe Docker is playing whack a mole with these vulnerabilities and preventing this is going to be near impossible.

Container safety is about restricting what can happen when your application gets owned, not about randomly running potential malware.

Verify, then Trust

I don’t want to sound like a broken record, but I’ve covered this before. The problem isn’t the privilege escalation, it’s that users are running untrusted images and expecting Docker to protect them against potentially malicious software.

Docker shouldn’t be about running random crap from the Internet (as root, no less!) and expecting not to be hacked.

Make no mistake, we will do everything we can to have a timely (but tested) asynchronous release when we identify real security vulnerabilities in the software we ship. These “vulnerabilities,” however, are easily prevented by sane computing practices.

Debugging container applications can be frustrating. Last week a few of us got together to hack on Atomicapp and the Nulecule specification. The codebase was moving fast, so I hit a few bugs. The problem was the application I was running was in a container and the bug was difficult to reproduce on my local workstation. The python traceback output suggested it was a simple fix so I wanted to just edit the code in place in the container and keep moving. But then how would I get the code onto my local development box and into my git repository? And how could I test this code change?

My approach was to bindmount the source from the local workstation into the container so the files being edited can remain in the local git repository.

Last Thursday night, we held the first-ever Docker meetup in Brno. Approximately 100 people gathered to hear speakers from four different organizations on container technology and its use. The space, video recordings (links coming soon) and catering were provided through support from Red Hat’s Open Source and Standards Team, Impact Hub, Good Data, and Seznam.cz.

Those of us in Project Atomic have been creating a platform-neutral specification, called Nulecule (noo-le-kyul), to help developers and admins build and launch composite, multi-container applications. You’ll find an excellent description of the problem and our solution at the RHEL Blog.

We’ve also created Atomic App as a way to run these applications using the Nulecule spec. If you just want to dive in and do stuff, just follow those links and go crazy. Read on for more.

Our own Daniel Riek wrote a great blog post about CoreOS’s current efforts around the appc specification, rkt, and the significant work that remains.

This is where it gets interesting:

We have added a new tool called atomic which I announced last week.

The Atomic tool currently takes advantage of the Label patch in docker that allows developers shipping applications as container images, to add arbitrary labels to the images json data. We chose to use some top level names for identifiers. Right now, Labels support free-form text without any restrictions. This is good in that it’s flexible, but bad in that we want containers to be portable and tools like Atomic that make use of the Label should co-exist with other tools that may also use the Label.

Just over a week ago, I headed to the outskirts of San Francisco’s Financial District to attend Container Camp, a one-day, single-track conference focused primarily on the Docker ecosystem.

The Container Camp lineup included a nice mix of project talks and real user stories that left me looking forward to attending the next time the crew comes to town, and thinking back on the key issues raised during the event.

Docker has added a new feature to allow alternate logging drivers, and soon you’ll be able to use journald as a supported driver.

With Docker 1.6 they support json-file, which is the old default, syslog, or no logging at all.

Last week I had the opportunity to attend Container.Camp in San Francisco and present an introduction to Project Atomic. If you didn’t get to attend – or just want to relive the talk – you can find it on YouTube (also embedded below).

If you’d like to see all of the Container.Camp presentations, they’re available on YouTube under the Container.Camp channel. Thanks again to the Container.Camp organizers for inviting me to speak, it was a great event. Fantastic speakers, really interesting venue, and a great crowd.

Earlier this week, VMware launched its lightweight operating system tailored for running Linux containers. Naturally, I was interested to see what VMware was cooking up, since that’s the same target we have for Project Atomic.

First, it’s great to see more interest in solving the problem of running Linux containers at scale. Even better, VMware seems to be interested in doing its work in the open. It’s always great to see companies that traditionally lean towards proprietary software taking steps towards doing more open source work. More open source work, even when it’s similar to other projects, is almost always a Good Thing™.

That said, I’d like to encourage VMware to consider whether they need to start from scratch with Project Photon. Creating an operating system from scratch is not trivial in the least, and there’s a lot of work that could be shared between Photon and Atomic.