Bug 1418464 - openscap container should use fully-qualified image name when installing /etc/atomic.d/openscap
Summary: openscap container should use fully-qualified image name when installing /etc...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openscap-container
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Martin Preisler
QA Contact: Matus Marhefka
: 1434110 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-02-01 21:57 UTC by Micah Abbott
Modified: 2017-04-12 14:55 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-04-12 14:55:16 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0964 0 normal SHIPPED_LIVE Red Hat Enterprise Linux Atomic openscap Container Image Update 2017-04-12 19:02:41 UTC

Description Micah Abbott 2017-02-01 21:57:04 UTC
The latest version (d1c039c76915) of the openscap container from Jan 30, 2016 currently installs a version of '/etc/atomic.d/openscap' that has an 'image_name' value which is not qualified with a domain.

# atomic images list
   REPOSITORY                                                                TAG      IMAGE ID       CREATED            VIRTUAL SIZE   TYPE      
   registry.access.redhat.com/rhel7/openscap                                 latest   d1c039c76915   2017-01-30 14:14   397.94 MB      docker    
   brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/ose-pod   v3.4     34d3450d733b   2017-01-27 20:18   204.97 MB      docker    
   registry.access.redhat.com/rhel7/kubernetes-scheduler                     latest   b83f92b1acae   2017-01-16 19:30   504.22 MB      docker    
   registry.access.redhat.com/rhel7/kubernetes-controller-mgr                latest   14fb4327b709   2017-01-16 19:30   504.22 MB      docker    
   registry.access.redhat.com/rhel7/kubernetes-apiserver                     latest   9072215ea9ef   2017-01-16 19:02   504.22 MB      docker    
   registry.access.redhat.com/rhel7                                          latest   e4b79d4d89ab   2017-01-12 20:51   192.53 MB      docker    

# atomic install registry.access.redhat.com/rhel7/openscap
docker run --rm --privileged -v /:/host/ registry.access.redhat.com/rhel7/openscap sh /root/install.sh

Installing the configuration file 'openscap' into /etc/atomic.d/.  You can now use this scanner with atomic scan with the --scanner openscap command-line option.  You can also set 'openscap' as the default scanner in /etc/atomic.conf.  To list the scanners you have configured for your system, use 'atomic scan --list'.

Saving current config.ini as config.ini.2017-02-01-21:49:22.atomic_save
Updating config.ini with latest configuration
Installation complete. You can customize /etc/oscapd/config.ini as needed.

# cat /etc/atomic.d/openscap 
type: scanner
scanner_name: openscap
image_name: rhel7/openscap
default_scan: cve
custom_args: ['-v', '/etc/oscapd:/etc/oscapd:ro']
scans: [ 
      { name: cve,
        args: ['oscapd-evaluate', 'scan',  '--no-standard-compliance', '--targets', 'chroots-in-dir:///scanin',  '--output', '/scanout'],
        description: "Performs a CVE scan based on known CVE data"},
      { name: standards_compliance,
        args: ['oscapd-evaluate', 'scan', '--targets', 'chroots-in-dir:///scanin',  '--output', '/scanout', '--no-cve-scan'],
        description: "Performs a standard scan"

On a RHEL system, this is not an issue because the docker daemon is configured with '--add-registry registry.access.redhat.com'.  However, non-RHEL hosts may not have this configuration and will default to using 'docker.io' as the registry and try to pull 'docker.io/rhel7/openscap' when the user tries to use 'atomic scan'

While unlikely that non-RHEL hosts would be using this image, I still think it would be useful to fully qualify the value of 'image_name' to 'registry.access.redhat.com/rhel7/openscap' in order to avoid any potential confusion.

Comment 2 Martin Preisler 2017-03-20 18:16:06 UTC
*** Bug 1434110 has been marked as a duplicate of this bug. ***

Comment 8 errata-xmlrpc 2017-04-12 14:55:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.