Project News

Automate Building Atomic Host

Project Atomic hosts are built from standard RPM packages that have been composed into filesystem trees using rpm-ostree. This guide provides an example of automating building and testing new Atomic Host ostrees.

One of the primary benefits to Atomic Host and OSTree has been the ability to configure once, deploy many times using custom OSTree images. But the process for doing so wasn’t streamlined or well-documented. I’m helping change that. I’m going to describe how to build atomic host in automated way. At the end of the article you’ll be able to create VM from QCOW2 image which is going to boot your own OSTree. The VM can also be used for testing Atomic Host releases (please feel free to open an issue if you find anything).

Read More »

Fedora's First Ever Container Layered Image Release

On behalf of the Fedora Atomic WG and Fedora Release Engineering, I am pleased to announce the first ever Fedora Layered Image Release. From now on we will be doing regularly scheduled releases of Fedora Layered Image content that will match the Fedora Atomic Two Week Release schedule.

Each Container Image is released with the following streams which aim to provide lifecycle management choices to our users:

Name
Name-Version
Name-Version-Release

Each of the Name and Name-Version tags will be updated in place with their respective updates for as long as the maintainer supports them and the Name-Version-Release will always be a frozen in time reference to that particular release of the Container Image.

Read More »

New CentOS Atomic Host with Updated Docker, Kubernetes and Etcd

An updated version of CentOS Atomic Host (tree version 7.20170209), is now available, including significant updates to docker (version 1.12.5), kubernetes (version 1.4) and etcd (version 3.0.15).

CentOS Atomic Host is a lean operating system designed to run Docker containers, built from standard CentOS 7 RPMs, and tracking the component versions included in Red Hat Enterprise Linux Atomic Host.

CentOS Atomic Host is available as a VirtualBox or libvirt-formatted Vagrant box, or as an installable ISO, qcow2 or Amazon Machine image. These images are available for download at cloud.centos.org. The backing ostree repo is published to mirror.centos.org.

CentOS Atomic Host includes these core component versions:

  • atomic-1.14.1-5.el7.x86_64
  • cloud-init-0.7.5-10.el7.centos.1.x86_64
  • docker-1.12.5-14.el7.centos.x86_64
  • etcd-3.0.15-1.el7.x86_64
  • flannel-0.5.5-2.el7.x86_64
  • kernel-3.10.0-514.6.1.el7.x86_64
  • kubernetes-node-1.4.0-0.1.git87d9d8d.el7.x86_64
  • ostree-2016.15-1.atomic.el7.x86_64
  • rpm-ostree-client-2016.13-1.atomic.el7.x86_64

Containerized kubernetes-master

The downstream release of CentOS Atomic Host ships without the kubernetes-master package built into the image. Instead, you can run the master kubernetes components (apiserver, scheduler, and controller-manager) in containers, managed via systemd, using the service files and instructions on the CentOS wiki. The containers referenced in these systemd service files are built in and hosted from the CentOS Community Container Pipeline, based on Dockerfiles from the CentOS-Dockerfiles repository.

These containers have been tested with the kubernetes ansible scripts provided in the upstream contrib repository, and they work as expected, provided you first copy the service files onto your master.

For more information, see the CentOS project blog or the CentOS Atomic download page.

Add a comment »

Tightening Up SELinux Policy for Containers

I wrote a blog post a couple of weeks ago explaining how SELinux can block breakout of processes in containers using when exploiting a vulnerability in the /usr/bin/docker-runc or /usr/bin/runc executable. At the time, I explained that the policy for container_t was blocked from writing to most parts of the OS other the container content labeled container_file_t. Despite blocking writes, though, it still allowed reads of some files.

A few people were alarmed when they realized that SELinux would block the breakout on writes but there is a chance for information leakage into the container. The usual example was the ability to read /etc/passwd from the host. But this isn’t unlimited access to the host. If the same container processes tried to read /etc/shadow on the hosts, or content in users home directories, or database data in /var, they would be blocked.

Read More »