We’re pleased to announce that Red Hat Enterprise Linux Atomic Host 7.4 is now generally available. Red Hat Enterprise Linux Atomic Host is a lightweight, container-optimized version of Red Hat Enterprise Linux. Red Hat Enterprise Linux Atomic Host couples the flexible, modular capabilities of Linux containers with the reliability and security of Red Hat Enterprise Linux in a reduced footprint, to decrease the attack surface and provide only the packages needed to light up hardware and run containers. Here’s a look at some of the major changes in 7.4.
Continue reading “What’s New in Red Hat Enterprise Linux Atomic Host 7.4?”
Recently, I spotted a question on a mailing list asking how to move container images from an internal/build registry to a production one. To put it another way: how would you copy images from registry A to registry B? I’m going to show you a really easy way to do this with skopeo.
Continue reading “Skopeo Copy to the Rescue”
We’re excited to announce our latest step in the further optimizing of Red Hat Enterprise Linux (RHEL) for containers with the release of the RHEL Atomic base image. This image is much smaller than the current RHEL base image, giving just enough to get started on building your application or service.
We carved out python, systemd, and yes, even Yum is gone – leaving you with only the bare bone essentials like glibc, rpm, bash, and their remaining dependencies. This leaves us with an image that’s just under 30MB compressed, 75MB on disk; composed of 81 packages.
Continue reading “Introducing the Red Hat Enterprise Linux Atomic Base Image”
A new CVE, (CVE-2016-9962), for the docker container runtime and runc were recently released. Fixed packages are being prepared and shipped for RHEL as well as Fedora and CentOS. This CVE reports that if you
execd into a running container, the processes inside of the container could attack the process that just entered the container.
If this process had open file descriptors, the processes inside of the container could
ptrace the new process and gain access to those file descriptors and read/write them, even potentially get access to the host network, or execute commands on the host.
Continue reading “SELinux Mitigates container Vulnerability”
Does your team want to move as quickly as possible? Are you and your development team looking for the latest features and not necessarily optimizing on stability? Are you just beginning with the docker runtime and not quite ready for container orchestration? Well, we have the answer, and it’s called the docker-latest package.
About 6 months ago, Red Hat added a package called docker-latest. The idea is to have two packages in Red Hat Enterprise Linux and Red Hat Enterprise Linux Atomic Host. A very fast moving docker-latest package and a slower, but more stable package called, well of course, docker.
The reasoning is, the larger and more sophisticated your container infrastructure becomes, a more stable version is often what people want – but when split into small agile teams, or when just starting out, many teams will optimize on the latest features in a piece of software. Either way, we have you covered with Red Hat Enterprise Linux and Red Hat Enterprise Linux Atomic Host.
Continue reading “Container Tidbits: Understanding the docker-latest Package”
Did you know there is an option to drop Linux capabilities in Docker? Using the
docker run --cap-drop option, you can lock down root in a container so that it has limited access within the container. Sadly, almost no one ever tightens the security on a container or anywhere else.
The Day After is Too Late
There’s an unfortunate tendency in IT to think about security too late. People only buy a security system the day after they have been broken into.
Dropping capabilities can be low hanging fruit when it comes to improving container security.
What are Linux Capabilities?
According to the capabilities man page,
capabilities are distinct units of privilege that can be independently enabled or disabled.
The way I describe it is that most people think of root as being all powerful. This isn’t the whole picture, the
root user with all capabilities is all powerful. Capabilities were added to the kernel around 15 or so years ago to try to divide up the power of root.
Continue reading “Secure Your Containers with this One Weird Trick”
We often compare the security of containers to virtual machines and ask ourselves “…which is more secure?” I have argued for a while now that comparing containers to virtual machines is really a false premise – we should instead be comparing containers to
Continue reading “Container Tidbits: The Tenancy Scale”
In our third and final installment (see: part one & part two), let’s take a look at some high-level use cases for Linux containers as well as finally (finally) defending what I like to call “pet” containers. From a general perspective, we see three repeated high-level use cases for containerizing applications:
- The fully orchestrated, multi-container application as you would create in OpenShift via the Red Hat Container Development Kit;
- Loosely orchestrated containers that don’t use advanced features like application templates and Kubernetes; and
- Pet containers.
Continue reading “In Defense of the Pet Container, Part 3: Puppies, Kittens and… Containers”
Red Hat Enterprise Linux Atomic Host is a small footprint, purpose-built version of Red Hat Enterprise Linux that is designed to run containerized workloads. Building on the success of our last release, Red Hat’s Atomic-OpenShift team is excited to announce the general availability of Red Hat Enterprise Linux Atomic Host 7.2.6. This release features improvements in rpm-ostree, cockpit, skopeo, docker, and the atomic CLI. The full release notes can be found here. This post is going to explore a major new feature
Continue reading “Announcing Red Hat Enterprise Linux Atomic Host 7.2.6”
Red Hat engineers have been working to more securely distribute container images. In this post we look at where we’ve come from, where we need to go, and how we hope to get there.
When the Docker image specification was introduced it did not have a cryptographic verification model. The most significant reason (for not having one) was the lack of a reliable checksum hash of image content. Two otherwise identical images could have different checksum values. Without a consistent tarsum mechanism, cryptographic verification would be very challenging. With Docker version 1.10, checksums are more consistent and could be used as a stable reference for
Continue reading “Container Image Signing”