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
