Create automated image builds

[bittner]

Planned tasks to refactor modsecurity-crs-docker

• Move the Docker setup from owasp-modsecurity-crs (/util/docker) to the new modsecurity-crs-docker repository
• Automate building images for all supported CRS versions on the various flavors of the modsecurity-docker images

Related issues:

• Make ModSecurity CRS repositories easier to manage SpiderLabs/owasp-modsecurity-crs#1600
• Consolidate development of Docker images modsecurity-docker#32

[bittner]

Having started with refactoring the owasp/modsecurity-crs Docker image I figured that there is probably very little benefit to overwhelm developers with a full choice of

• the ModSecurity version (2 or 3)
• the Web proxy platform (Apache, Nginx, more in future)
• the CRS version

It's probably sufficient to satisfy the use case of wanting to choose the CRS version (primarily) and the Web proxy platform. Because as a developer you may want to use "the latest version of ModSecurity, with the CRS obviously" targeting a specific Web proxy software.

Docker Image Tagging Scheme

Hence, a Dockerfile a developer may want to code could start like this:

FROM owasp/modsecurity-crs:3.3-apache

FROM owasp/modsecurity-crs:3.3-nginx

And while the Nginx flavor would run ModSecurity v3, the Apache flavor would run ModSecurity v2 underneath for plain technical reasons, and no-one should care. The CRS will be the same and the resulting behavior should (hopefully) also match.

FROM owasp/modsecurity-crs:3.3

FROM owasp/modsecurity-crs:apache

FROM owasp/modsecurity-crs:nginx

Whether just specifying the CRS version would default to Nginx or better Apache shall be defined later on, maybe based on popularity or obvious technical advantage (stability, speed). When I specify only the Web proxy platform I should get the latest CRS, following the way the httpd and nginx base images do it.

Outcome

This decision would reduce both the mental overhead for developers using the image and the maintainers of the image, reducing the number of combinations.

Does that sound okay or are there reasons to stick to a different tagging scheme?

Pinging @csanders-git, @franbuehler, @dune73.

[bittner]

More design decisions:

• The ModSecurity configuration files will live in /opt/modsecurity and will only by symlinked into the Web proxy's configuration
• The CRS files will live in /opt/owasp-crs and will only be symlinked into the ModSecurity configuration
• More tools and configuration related to ModSecurity or CRS may also live in /opt (scripts or binaries therein will be symlinked in /usr/local/bin to have them easily executed from anywhere)

This way it should be possible to configure ModSecurity the same way (at the same file locations) completely agnostic from which Web proxy is being used.

[franbuehler]

Thanks for pinging me and thanks for your proposals, @bittner . I like them!
I like the idea of reducing the number of images and making it easier for developers to choose an image. You're right, the other combinations of webservers and ModSecurity versions probably don't make sense at the moment. And it's easier for our project if we have to maintain less images.
The tagging scheme makes sense.

I also like the idea of copying files to the mentioned directories and just linking them.

So we could do it the way you proposed, in my opinion. Other opinions?

[bittner]

The automatic builds are now in place. The following images (tags) are added/updated on Ducker Hub:

• 3.3, 3.3-apache, apache
• 3.3-nginx, nginx

The latest tag is not updated yet (to avoid affecting everyone's daily business).