In my previous article where I introduced atomic scan, I largely talked about using atomic to scan your containers and images for CVE Vulnerabilities. I also discussed how atomic scan had been architected to a plug-in approached so that you can implement your own scanners. The plug-ins do not have to focus on vulnerabilities, it could be as simple a scanner that collects information about containers and images.
In this blog, I will walk through how you can create your own custom scanner within the atomic plug-in framework.
Continue reading “Creating a custom atomic scan plug-in”
In the world of containers, there is a desperate need to be able to scan container images for known vulnerabilities and configuration problems, and as we proliferate containers and bundled applications into the enterprise, many groups and companies have started to build container scanning tools. Even Red Hat has been building a scanning tool based on the tried and true OpenSCAP project, but there were several problems we saw time and again.
The problems with existing container scanning tools included:
- Either these tools were required to be installed on the host, or if they were installed via a container they would have to be very privileged; therefore, the containers themselves could use that authority on the host machine.
- They were being hard coded to only support a single container framework – docker.
- We saw some very slow implementations, where the container scanning tools were actually copying all of the content out of the container image, then scanning the content, and finally removing the content. You can image how inefficient this could be for hundreds or thousands of images or containers.
We decided we wanted to build a tool, atomic scan, that understood the underlying architecture and could download and run containers with scanning tools in them. But, we also didn’t want the scanning tools to be privileged; the atomic tool would be able to mount up read only rootfs from the host’s file system. These mounted file systems could then be passed onto the scanning container, along with a writeable directory for the scanner to place its output.
Continue reading “Introducing atomic scan – Container vulnerability detection”
This blog is a continuation of “Creating custom Atomic trees, images, and installers – Part 1.” In part one, we learned how to compose our own atomic trees and consume them in a guest. In part two, we will learn how to create our own disk images and installer media.
Creating custom disk images
As mentioned in the previous blog, the subcommand imagefactory can be used to create disk images. As of this writing, the imagefactory subcommand can output the following image types:
- kvm – results in a qcow2 image perfect for importing with KVM
- raw – a raw image, which can be used as it or converted to another type
- vsphere –
- rhevm – suitable image for importing into RHEV-M
Continue reading “Creating custom Atomic trees, images, and installers – Part 2”
Not too soon after people start using Atomic images, the question of customization soon follows. It is a natural progression for most people when they use Atomic. There are a number of different ways to accomplish using custom images not withstanding using docker and containers. The Atomic tool called ‘rpm-ostree-toolbox‘ is emerging as the best tool for customizing Atomic.
The ‘rpm-ostree-toolbox’ main command is actually a wrapper (much like virsh) for three subcommands: treecompose, imagefactory, and installer. With these three subcommands, you can create:
- a custom Atomic tree
- customized disk images (qcow2 and the like) based on your tree
- install media (ISO) that installs your tree
Continue reading “Creating custom Atomic trees, images, and installers – Part 1”