In the following article we will present a method how to perform a Security Content Automation Protocol (SCAP) based benchmark validation of (selected) container images deployed on the top of the Red Hat Enterprise Linux Atomic Host.
The security benchmark validation will be performed utilizing the services of the oscap-docker tool and we will scan the container images against the Red Hat Enterprise Linux 7 benchmark from scap-security-guide repository.
Originally introduced in Red Hat Enterprise Linux 7 Update 1, the Red Hat Enterprise Linux Atomic Host is a “secure, minimal footprint operating system optimized to run Linux containers“. Though Red Hat Enterprise Linux Atomic Host being a variant of the Red Hat Enterprise Linux Server product, the methodology of its design implies there are specific features, making the process of scanning container images deployed on this platform unique. While in the following we will not dedicate focus to describe every particularity of the Atomic variant, it is necessary first to consider selected differences, having impact on the scan process.
- since the Red Hat Enterprise Linux Atomic Host is not managed in the same way as other Red Hat Enterprise Linux 7 variants, instead of installing the oscap-docker tool directly on the host, we will need to install it into dedicated container image. In other words we will reserve one container image (in the later text referenced as “scanning container“) in order to hold the installed oscap-docker tool and perform the scanning service for other containers,
- as we want to be able to scan every container image applied on the Red Hat Enterprise Linux Atomic Host (including the “scanning” one), the scanning container will need to be run as a super-privileged one (ability to scan every container image present on the host means we need to be able to identify their count and some of their characteristics, like e.g. name of each of the container images to subsequently supply it to the “oscap-docker” process). Again, for brevity we will not further describe all the possibilities (and consequences) of running a container image in the super-privileged mode. Refer to e.g. for details if further interested into this description.
Based on previous two requirements, what we have now being a dedicated scanning container able to access selected file system locations of the host system. But this is still not enough to be able to retrieve the list of all available container images present on the Red Hat Enterprise Linux Atomic Host, and to run “oscap-docker” scans on them. Therefore we will fine-tune the requirements below yet:
- we will use – -ipc=host, – -net=host, and – -pid=host options applied, when running the scanning container (in order the oscap-docker process to share the network, process table and IPC functionality with the host system),
Important: Do not use these settings by default when running scan of container images in the production environment, without further understanding of the effect caused by using each of these options.
- additionally to the above, when running the scanning container we will share the docker binary location between the Red Hat Enteprirse Linux Atomic Host and scanning container (to be able to get the list of container images present on the host), and also in the same way share the docker local Unix socket.
In this moment we have sufficient information to proceed to the preparation of the scanning container image itself. The initial environment below assumes the following conditions:
- Red Hat Enterprise Linux Atomic Host is installed and registered (to enable software updates),
- the “rhel7” and “rhel7/rsyslog” container images have been pulled on the top of this host,
List of container images on this host therefore looks as follows (there might be actually more of the container images installed, just “rhel7” and “rhel7/rsyslog” are required for the scenario we present below to work):
Next we need to slightly enhance the scanning container image (former “rhel7” container image) to include the “oscap-docker” tool. We do this by installing the most recent “openscap-utils” RPM package from OpenSCAP COPR repository (starting from OpenSCAP-1.2.4 release, the “oscap-docker” tool has been included to be shipped natively within OpenSCAP releases). We launch the “rhel7” container image:
# docker run -it rhel7
verify proper settings of the OpenSCAP’s COPR EPEL-7 repository, and install the “openscap-utils” RPM package:
Besides openscap-utils package we will need couple of additional RPM packages to be installed in the scanning container image. These include (Note: possible dependent packages that would be automatically installed by the “yum” utility are not incorporated in the listing below):
- “git“ in order to clone latest scap-security-guide Git repository content,
- “python-lxml“ and “make” in order to be able to build the scap-security-guide RPM package, and
- “xml-common” to be able to install the built scap-security-guide RPM.
As a next step, we clone the “scap-security-guide” repository content, build the scap-security-guide RPM package in the running “rhel7” container image:
and install the RPM we have just built:
Since we want the scanning container image to be re-usable also in the future, we need to “commit“ the changes performed against the vanilla “rhel7” container image. Therefore having had returned to the main Red Hat Enterprise Linux Atomic Host shell, we commit the new container image (it can be launched later under the new “rhel7_oscap_docker” name):
In this moment we have all the prerequisites set in order to be able to perform the another container image scan using the scanning container. We start the “rhel7_oscap_docker” (scanning container) applying the command-line options as shown on the following image. We also try to obtain the list of container images being present on this Red Hat Enterprise Linux Atomic Host:
As can be seen in the previous image the attempt to run “docker images” command failed due to docker daemon, when run from the scanning container missing the location of the “libdevmapper.so.1.02” dynamic shared object (DSO). Therefore we need to adjust the content of the “LD_LIBRARY_PATH” environment variable yet with the proper location of this DSO file. On bare-metal system this file is located under the “/usr/lib64” location (under assumption we are running x86_64 version of the Red Hat Enterprise Linux Atomic Host). But since in the previous command we have exported the root (“/”) storage volume of the Red Hat Enterprise Linux Atomic Host under the “/host” volume, we need to prefix standard location with this volume path yet. So we issue the following command:
Now we have everything set to be able to perform the “oscap-docker” scan of the “rhel7/rsyslog” container image using the “common” profile of the Red Hat Enterprise Linux 7 SCAP benchmark from the scap-security-guide repository.
To scan the “rhel7/rsyslog” container using the XCCDF form of the benchmark:
Once the scan of the “rhel7/rsyslog” container image has finished, the produced oscap HTML report files (“rsyslog_xccdf_scan_report.html” and “rsyslog_datastream_scan_report.html” respectively) can be inspected in a web browser to verify if the container image is compliant with the requested benchmark or not.
As can be seen the “rhel7/rsyslog” container image meets the rsyslog service specific (“Ensure rsyslog is Installed”, and “Enable rsyslog Service”) rules.