Hi, after discussion within the OpenSCAP team we decided to:
* Remove the outdated Dockerfiles (atomic [1] and atomic-git [2] directories). * Provide a configurable build script which will be able to build openscap docker container image either from RPM packages or from the upstream sources. One of the benefits of having this configurable build script is ability to develop and test rules for container images hardening (which should be available in future under "atomic scan" command with the "--harden" option). The example workflow: 1. Write new profiles/rules to scap-security-guide, or enhancements to openscap or openscap-daemon code. 2. Use the build script to build openscap docker container image with openscap-daemon, openscap-utils and scap-security-guide bundled inside the image (in this case compiled from the upstream sources to reflect all the updates in the step 1). 3. Harden chosen docker image using "atomic scan --harden" to be compliant with some standard profile (for example harden rhel7 base image using the xccdf_org.ssgproject.content_profile_ospp-rhel7 profile). The "atomic scan --harden" command will use the updated openscap docker container image built in the step 2 as a scanner. This command will first check the image for compliance with the selected profile, it will generate fix for failing rules and then it will apply that fix which will form a new "hardened" image. [1] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic [2] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic-git Regards, Matus Marhefka On Thu, Jun 22, 2017 at 2:24 PM, Jan Cerny <jce...@redhat.com> wrote: > Hi, > > I would like to move the discussion about Dockerfiles for OpenSCAP > container > from GitHub [1] to the mailing list, because I'm interested in solving that > topic. > > Nowadays, OpenSCAP Deamon upstream repository contains multiple Dockerfiles > in this repository to build various container images with OpenSCAP. There > are > Dockerfiles to build either from packages [2] or from latest upstream code > [3]. > > The problem is that the Dockerfiles are outdated. They used to be to > demonstrate > "atomic scan", but now we ship an image called "openscap" in Red Hat > Registry. > Moreover, upstream dockerfiles are very different from what is used to > build > image registry.access.redhat.com/rhel7/openscap. Also there is a lot of > duplication > in the repository, because the multiple variants are almost the same. > > Firstly, I think that for testing and development it would be beneficial > to have > a Dockerfile that will enable upstream community to build an image that is > very similar > to registry.access.redhat.com/rhel7/openscap, but with fresh OpenSCAP > daemon from upstream git. > > Also, the new Dockerfile and other files can be used as a template for > downstream > container builds. > > There are multiple solutions: > > * Keep the current directory structure in atomic and atomic-git. > Update all current Dockerfiles, add all the files. However I'm afraid > that > there will be a lot of duplicates. > > * Remove the atomic and atomic-git. Make a new directory, that would > contain Dockerfile > and other files. We can reuse the files that are now used for our > container image > in Red Hat Registry. > > * Make a script that creates a Dockerfile and all the required files and > builds > the image. It could be parametrizable, so the user could choose base > image, > versions of packages (usptream/distro), developer's branches, etc. > > I use now this workflow: > I have a Dockerfile on my laptop, I have a script that creates an image > (based on Fedora) with fresh upstream OpenSCAP Daemon. The image is > tagged as 'openscap:testing'. Then I just configure the image name in > '/etc/atomic.d/openscap' and Atomic uses it instead of > registry.access.redhat.com/rhel7/openscap automatically. This seems to me > really easy and works OK so far. > > Are we interested to include something like that into upstream? > > What are your opinions on our upstream Dockerfiles? [2] [3] > > Regards > > > > [1] https://github.com/OpenSCAP/openscap-daemon/issues/102 > [2] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic > [3] https://github.com/OpenSCAP/openscap-daemon/tree/master/atomic-git > > > Jan Černý > Security Technologies | Red Hat, Inc. > > > _______________________________________________ > Open-scap-list mailing list > Open-scap-list@redhat.com > https://www.redhat.com/mailman/listinfo/open-scap-list
_______________________________________________ Open-scap-list mailing list Open-scap-list@redhat.com https://www.redhat.com/mailman/listinfo/open-scap-list