7.6. Using OpenSCAP with Atomic
atomic scancommand allows users to utilize OpenSCAP scanning capabilities to scan their docker-formatted container images and containers present on the system. It is possible to scan for known CVE vulnerabilities or for configuration compliance.
Atomic Scan and OpenSCAP Scanner Image
atomictool for container management, enter the following command:
yum install atomic
atomictool is installed, you also need a scanner which is used by the
atomic scancommand as a backend for scanning images and containers. Red Hat recommends choosing the OpenSCAP scanner bundled in the rhel7/openscap container image which is located in the registry.access.redhat.com image registry:
atomic scancommand. It currently supports two scan types targeting Red Hat Enterprise Linux systems. To list supported scan types, enter the following command:
--containersdirective, respectively. To scan both types, use the
--alldirective. The list of available command-line options can be obtained using
atomiccommand usage and containers, see the Product Documentation for Red Hat Enterprise Linux Atomic Host. The Red Hat Customer Portal also provides a guide to the Atomic command line interface (CLI).
7.6.1. Scanning Docker Images and Containers for Vulnerabilities Using Atomic
atomic scancommand is CVE scan. Use it for checking the target for known security vulnerabilities as defined in the CVE OVAL definitions released by Red Hat.
--verbosedirective and without it):
As you can see, the CVE scan of the latest Red Hat Enterprise Linux 7 container image does not contain any known security vulnerabilities while the older version of this container image (version 7.2) contains multiple of them. By using the CVE scan feature of the
--verboseregistry.access.redhat.com/rhel7:latest docker run -t --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2017-11-01-14-55-37-758180:/scanin -v /var/lib/atomic/openscap/2017-11-01-14-55-37-758180:/scanout:rw,Z -v /etc/oscapd:/etc/oscapd:ro registry.access.redhat.com/rhel7/openscap oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout WARNING:Can't import the 'docker' package. Container scanning functionality will be disabled. INFO:Creating tasks directory at '/var/lib/oscapd/tasks' because it didn't exist. INFO:Creating results directory at '/var/lib/oscapd/results' because it didn't exist. INFO:Creating results work in progress directory at '/var/lib/oscapd/work_in_progress' because it didn't exist. INFO:Evaluated EvaluationSpec, exit_code=0. INFO:Evaluated EvaluationSpec, exit_code=0. INFO:[100.00%] Scanned target 'chroot:///scanin/db7a70a0414e589d7c8c162712b329d4fc670fa47ddde721250fb9fcdbed9cc2' registry.access.redhat.com/rhel7:latest (db7a70a0414e589) registry.access.redhat.com/rhel7:latest passed the scan Files associated with this scan are in /var/lib/atomic/openscap/2017-11-01-14-55-37-758180.
atomic scanregistry.access.redhat.com/rhel7:7.2 docker run -t --rm -v /etc/localtime:/etc/localtime -v /run/atomic/2017-11-01-14-49-36-614281:/scanin -v /var/lib/atomic/openscap/2017-11-01-14-49-36-614281:/scanout:rw,Z -v /etc/oscapd:/etc/oscapd:ro registry.access.redhat.com/rhel7/openscap oscapd-evaluate scan --no-standard-compliance --targets chroots-in-dir:///scanin --output /scanout registry.access.redhat.com/rhel7:7.2 (98a88a8b722a718) The following issues were found: RHSA-2017:2832: nss security update (Important) Severity: Important RHSA URL: https://access.redhat.com/errata/RHSA-2017:2832 RHSA ID: RHSA-2017:2832-01 Associated CVEs: CVE ID: CVE-2017-7805 CVE URL: https://access.redhat.com/security/cve/CVE-2017-7805 RHSA-2017:2016: curl security, bug fix, and enhancement update (Moderate) Severity: Moderate RHSA URL: https://access.redhat.com/errata/RHSA-2017:2016 RHSA ID: RHSA-2017:2016-01 Associated CVEs: CVE ID: CVE-2016-7167 CVE URL: https://access.redhat.com/security/cve/CVE-2016-7167 RHSA-2017:1931: bash security and bug fix update (Moderate) Severity: Moderate RHSA URL: https://access.redhat.com/errata/RHSA-2017:1931 RHSA ID: RHSA-2017:1931-01 Associated CVEs: CVE ID: CVE-2016-0634 CVE URL: https://access.redhat.com/security/cve/CVE-2016-0634 CVE ID: CVE-2016-7543 CVE URL: https://access.redhat.com/security/cve/CVE-2016-7543 CVE ID: CVE-2016-9401 CVE URL: https://access.redhat.com/security/cve/CVE-2016-9401 ............ Files associated with this scan are in /var/lib/atomic/openscap/2017-11-01-14-49-36-614281.
atomic scancommand you can easily discover if your container images contain known security vulnerabilities.
7.6.2. Scanning and Remediating Configuration Compliance of Docker Images and Containers Using Atomic
atomic scancommand is configuration_compliance scan, where you can use the SCAP content provided by the SCAP Security Guide (SSG) bundled inside the OpenSCAP container image for evaluation. This allows you to scan Red Hat Enterprise Linux based container images and containers against any profile provided by the SCAP Security Guide.
The output of the previous command will contain the information about files associated with the scan at the end:
............ Files associated with this scan are in /var/lib/atomic/openscap/2017-11-03-13-35-34-296606.The
tree/var/lib/atomic/openscap/2017-11-03-13-35-34-296606 /var/lib/atomic/openscap/2017-11-03-13-35-34-296606 ├── db7a70a0414e589d7c8c162712b329d4fc670fa47ddde721250fb9fcdbed9cc2 │ ├── arf.xml │ ├── fix.sh │ ├── json │ └── report.html └── environment.json 1 directory, 5 files
atomic scangenerates a subdirectory with all the results and reports from the scan in the /var/lib/atomic/openscap/ directory as can be seen in the previous code snippet. The arf.xml XML file with results is generated everytime when scanning for configuration compliance. The humand readable HTML report file (report.html) can be generated by adding the
reportsuboption to the
--scanner_argssuboptions are separated by the comma character. The specific values for the
profilesuboptions which are selecting an XCCDF component and a profile from selected datastream file are taken from the bundled SCAP content in the OpenSCAP image. The datastream file is selected automatically by the OpenSCAP image during scan based on the target container image or container which is being scanned.
xccdf-idsuboption of the
--scanner_argsoption is omitted, searching for a profile will be done in the first XCCDF component found in the selected datastream file. More details about datastream files can be found in the Section 7.2.3, “The Data Stream Format”.
Remediating Configuration Compliance of Docker Images and Containers Using Atomic
--remediateoption to the
atomic scancommand when scanning for configuration compliance. The following command builds a new remediated container image compliant with the DISA STIG policy from the Red Hat Enterprise Linux 7 container image:
First, the configuration compliance scan is run against the original container image to check its compliance with the DISA STIG policy. Based on the scan results fix script containing bash remediations for the failed scan results is generated. The fix script is then applied on the original container image, this is referred to as remediation. The result of remediation is a container image with altered configuration which is added as a new layer on top of the original container image. The output of
reportregistry.access.redhat.com/rhel7:latest registry.access.redhat.com/rhel7:latest (db7a70a0414e589) The following issues were found: ............ Configure Time Service Maxpoll Interval Severity: Low XCCDF result: fail Configure LDAP Client to Use TLS For All Transactions Severity: Moderate XCCDF result: fail ............ Remediating rule 43/44: 'xccdf_org.ssgproject.content_rule_chronyd_or_ntpd_set_maxpoll' Remediating rule 44/44: 'xccdf_org.ssgproject.content_rule_ldap_client_start_tls' Successfully built 9bbc7083760e Successfully built remediated image 9bbc7083760e from db7a70a0414e589d7c8c162712b329d4fc670fa47ddde721250fb9fcdbed9cc2. Files associated with this scan are in /var/lib/atomic/openscap/2017-11-06-13-01-42-785000.
atomic scancommand reports the remediated image ID (as highligted in the previous code snippet) which you can tag with some name so it is easy to remember:
It is important to note that the original container image will be kept unchanged and only on the top of it a new layer will be created, forming a new container image, that will contain all the configuration amendments. The content of this layer is defined by the security policy that we scan, in this case the DISA STIG policy. This also means that the remediated container image is no longer signed by Red Hat, but this is expected as it differs from the original container image because of the remediated layer.