Project News

We are pleased to announce Atomic App 0.1.1! Find it at github and docker hub.

Atomic App is the reference implementation of the Nulecule Specification for composite applications. It can be used to bootstrap container applications and to install/deploy and run them. One of the key design goals of the Nulecule spec is to be container and orchestration engine agnostic, so that any developer or operator could successfully build, test, install, run, and manage composite container applications regardless of tooling.

In that same vein, Atomic App is designed to be provider agnostic, whether you want to run your application in a Kubernetes, OpenShift, or plain container environment, like Docker. It’s this multi-provider support feature that we are emphasizing for this release: building a Nulecule application results in a portable container that can be run in a wide variety of environments, and Atomic App takes the Nulecule application container and allows the operator to easily run a composite application in their chosen environment with their chosen providers.

It is in the spirit of portability that we announce a major milestone for Atomic App: support for OpenShift v3 as a provider. And for developers of Nulecule applications, we have also added some new and exciting developer features.

Read More »

A quick note for folks who might have missed the announcement yesterday, Fedora 22 was officially released, along with Atomic images for OpenStack/KVM, Amazon EC2, and Vagrant.

The Vagrant images are suitable for VirtualBox and libvirt/KVM, so they’re usable on Linux (libvirt), or Mac OS X and Windows (VirtualBox) with the appropriate Vagrant providers. Josef Stříbný has written up a short tutorial on using Vagrant images on Fedora 22 on Fedora Magazine.

Of course, Fedora 22 also includes the Workstation and Server editions – and the Fedora 22 Docker image will be available via the Docker Hub very soon.

Questions or feedback on the Fedora 22 Atomic host release? Talk to us on the Fedora Cloud mailing list, or fire up your favorite IRC client and head to Freenode in the #fedora-cloud channel.

In this post I’ll show how to build live Atomic Host image that can be run on diskless machine using PXE boot. Once we have the images, I’ll show you how to run the live system and customize it with boot options and cloud-config for better use of resources, leading to the goal of storing Docker images on iSCSI devices.

Read More »

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.

Read More »