coreruleset · theseion · Jan 21, 2024 · Jan 24, 2024 · Jan 24, 2024 · Jan 27, 2024
diff --git a/README-containers.md b/README-containers.md
@@ -15,23 +15,50 @@
 
 The Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls.
 
-## Supported tags and respective `Dockerfile` links
+## Supported Tags
 
-* `3-nginx-YYYYMMDDHHMM`, `3.3-nginx-YYYYMMDDHHMM`, `3.3.5-nginx-YYYYMMDDHHMM`, `nginx` ([master/nginx/Dockerfile](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile)) – *last stable ModSecurity v3 on Nginx 1.25.3 official stable base image, and latest stable Core Rule Set 3.3.5*
-* `3-apache-YYYYMMDDHHMM`, `3.3-apache-YYYYMMDDHHMM`, `3.3.5-apache-YYYYMMDDHHMM`, `apache` ([master/apache/Dockerfile](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile)) –*last stable ModSecurity v2 on Apache 2.4.58 official stable base image, and latest stable Core Rule Set 3.3.5*
+### Stable Tags
 
-🆕 We added healthchecks to the images. Containers already return HTTP status code 200 when accessing the `/healthz` URI. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. See <https://docs.docker.com/engine/reference/builder/#healthcheck> for more information.
+Stable Tags are composed of:
+   * CRS version, in the fromat `<major>[.<minor>[.<patch]]`
+   * web server variant
+   * OS variant (optional)
+   * date, in the format `YYYYMMDDHHMM`
 
-## Supported variants
+The stable tag format is `<CRS version>-<web server>[-<os>]-<date>`.
+Examples:
+   * `3-nginx-202401121309`
+   * `3.3-apache-alpine-202401121309`
+   * `3.3.5-openresty-alpine-fat-202401121309`
 
-We also build [alpine linux](https://www.alpinelinux.org/) variants of the base images, using the `-alpine` suffix. Examples:
+### Rolling Tags
 
-* `3-nginx-alpine-YYYYMMDDHHMM`, `3.3-nginx-alpine-YYYYMMDDHHMM`, `3.3.5-nginx-alpine-YYYYMMDDHHMM`, `nginx-alpine` ([master/nginx/Dockerfile-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile-alpine) – *last stable ModSecurity v3 on Nginx 1.25.3 official alpine stable base image, and latest stable Core Rule Set 3.3.5*
-* `3-apache-alpine-YYYYMMDDHHMM`, `3.3-apache-alpine-YYYYMMDDHHMM`, `3.3.5-apache-alpine-YYYYMMDDHHMM`, `apache-alpine` ([master/apache/Dockerfile-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile-alpine)) – *last stable ModSecurity v2 on Apache 2.4.58 official alpine stable base image, and latest stable Core Rule Set 3.3.5*
+Rolling tags are updated whenever a new stable tag release occurs. Rolling tags can be practical but should not be used in production.
 
-## Production usage
+Rolling Tags are composed of:
+   * web server variant
+   * OS variant (optional)
 
-⚠️ We changed tags to [support production usage](https://github.com/coreruleset/modsecurity-crs-docker/issues/67). Now, if you want to use the "rolling version", use tags `owasp/modsecurity-crs:nginx` or `owasp/modsecurity-crs:apache`, or if you want the alpine variant use `owasp/modsecurity-crs:nginx-alpine` or `owasp/modsecurity-crs:apache-alpine`. If you need a stable long term image, use the one with the full CRS version, the variant used (if any), and the build date in `YYYYMMDDHHMM` format, example `owasp/modsecurity-crs:3.3.5-nginx-202209141209` or `owasp/modsecurity-crs:3.3.5-apache-alpine-202209141209` for example. You have been warned.
+The stable tag format is `<web server>[-<os>]`.
+Examples:
+   * `nginx`
+   * `apache-alpine`
+   * `openresty-alpine-fat`
+
+## OS Variants
+
+* nginx – *latest stable ModSecurity v3 on Nginx 1.25.3 official stable base image, and latest stable Core Rule Set 3.3.5*
+   * [nginx](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile)
+   * [nginx-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile-alpine)
+* Openresty - *last stable ModSecurity v3 on Nginx 1.25.3 official stable base image, and latest stable Core Rule Set 3.3.5*
+   * [openresty-alpine-fat](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/openresty/Dockerfile-alpine)
+* Apache httpd – *last stable ModSecurity v2 on Apache 2.4.58 official stable base image, and latest stable Core Rule Set 3.3.5*
+   * [apache](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile)
+   * [apache-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile-alpine)
+
+### Notes regarding Openresty version of this image
+
+We currently only provide a version of the Openresty image based on **Alpine Linux**. The Dockerfile for Openresty resides in the [docker-openresty repository](https://github.com/openresty/docker-openresty/blob/master/alpine/Dockerfile.fat).
 
 ## Supported architectures
 
@@ -40,6 +67,17 @@ We also build [alpine linux](https://www.alpinelinux.org/) variants of the base
 * linux/arm64/v8
 * linux/i386
 
+### Notes regarding Openresty version of the image
+
+Openresty image builds currently support only these architectures:
+
+* linux/amd64
+* linux/arm64
+
+## Container Health Checks
+
+🆕 We add healthchecks to the images, so that containers return HTTP status code 200 from the `/healthz` endpoint. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. See <https://docs.docker.com/engine/reference/builder/#healthcheck> for more information.
+
 ## Quick reference
 
 * **Where to get help**: the [Core Rule Set Slack Channel](https://owasp.org/slack/invite) (#coreruleset on owasp.slack.com), or [Stack Overflow](https://stackoverflow.com/questions/tagged/mod-security)
@@ -174,8 +212,6 @@ All these variables impact in configuration directives in the modsecurity engine
 
 | Name | Description|
 | -- | -- |
-| USER | Name (or #number) of the user to run httpd or nginx as (Default: `www-data` (httpd), `nginx` (nginx)) |
-| GROUP | Name (or #number) of the group to run httpd as (Default: `www-data`) |
 | BACKEND | Backend address (and optional port) of the backend server. (Default: the container's default router, port 81) (Examples: 192.0.2.2, 192.0.2.2:80, <http://172.17.0.1:8000>) |
 
 ### CRS specific

diff --git a/README.md b/README.md
@@ -12,36 +12,65 @@
 The Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls.
 ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx.
 
-## Supported tags and respective `Dockerfile` links
+## Supported Tags
 
-* `3-nginx-YYYYMMDDHHMM`, `3.3-nginx-YYYYMMDDHHMM`, `3.3.5-nginx-YYYYMMDDHHMM`, `nginx` ([master/nginx/Dockerfile](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile)) – *last stable ModSecurity v3 on Nginx 1.25.3 official stable base image, and latest stable Core Rule Set 3.3.5*
-* `3-apache-YYYYMMDDHHMM`, `3.3-apache-YYYYMMDDHHMM`, `3.3.5-apache-YYYYMMDDHHMM`, `apache` ([master/apache/Dockerfile](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile)) –*last stable ModSecurity v2 on Apache 2.4.58 official stable base image, and latest stable Core Rule Set 3.3.5*
+### Stable Tags
 
-⚠️ We changed tags to [support production usage](https://github.com/coreruleset/modsecurity-crs-docker/issues/67). Now, if you want to use the "rolling version", use the tag `owasp/modsecurity-crs:nginx` or `owasp/modsecurity-crs:apache`. If you need a stable long term image, use the one with the full CRS version, in addition to the build date in `YYYYMMDDHHMM` format, example `owasp/modsecurity-crs:3.3.5-nginx-202209141209` or `owasp/modsecurity-crs:3.3.5-apache-202209141209` for example. You have been warned.
+Stable Tags are composed of:
+   * CRS version, in the fromat `<major>[.<minor>[.<patch]]`
+   * web server variant
+   * OS variant (optional)
+   * date, in the format `YYYYMMDDHHMM`
 
-🆕 We added healthchecks to the images. Containers already return HTTP status code 200 when accessing the `/healthz` URI. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. See <https://docs.docker.com/engine/reference/builder/#healthcheck> for more information.
+The stable tag format is `<CRS version>-<web server>[-<os>]-<date>`.
+Examples:
+   * `3-nginx-202401121309`
+   * `3.3-apache-alpine-202401121309`
+   * `3.3.5-openresty-alpine-fat-202401121309`
 
-## Supported variants
+### Rolling Tags
 
-We also build [alpine linux](https://www.alpinelinux.org/) variants of the base images, using the `-alpine` suffix. Examples:
+Rolling tags are updated whenever a new stable tag release occurs. Rolling tags can be practical but should not be used in production.
 
-* `3-nginx-alpine-YYYYMMDDHHMM`, `3.3-nginx-alpine-YYYYMMDDHHMM`, `3.3.5-nginx-alpine-YYYYMMDDHHMM`, `nginx-alpine` ([master/nginx/Dockerfile-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile-alpine) – *last stable ModSecurity v3 on Nginx 1.25.3 official alpine stable base image, and latest stable Core Rule Set 3.3.5*
-* `3-apache-alpine-YYYYMMDDHHMM`, `3.3-apache-alpine-YYYYMMDDHHMM`, `3.3.5-apache-alpine-YYYYMMDDHHMM`, `apache-alpine` ([master/apache/Dockerfile-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile-alpine)) – *last stable ModSecurity v2 on Apache 2.4.58 official alpine stable base image, and latest stable Core Rule Set 3.3.5*
+Rolling Tags are composed of:
+   * web server variant
+   * OS variant (optional)
 
-⚠️ We changed tags to [support production usage](https://github.com/coreruleset/modsecurity-crs-docker/issues/67). Now, if you want to use the "rolling version", use the tag `owasp/modsecurity-crs:nginx-alpine` or `owasp/modsecurity-crs:apache-alpine`. If you need a stable long term image, use the one with the full CRS version, in addition to the build date in `YYYYMMDDHHMM` format, example `owasp/modsecurity-crs:3.3.5-nginx-alpine-202209141209` or `owasp/modsecurity-crs:3.3.5-apache-alpine-202209141209` for example. You have been warned.
+The stable tag format is `<web server>[-<os>]`.
+Examples:
+   * `nginx`
+   * `apache-alpine`
+   * `openresty-alpine-fat`
+
+## OS Variants
+
+* nginx – *latest stable ModSecurity v3 on Nginx 1.25.3 official stable base image, and latest stable Core Rule Set 3.3.5*
+   * [nginx](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile)
+   * [nginx-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/nginx/Dockerfile-alpine)
+* Openresty - *last stable ModSecurity v3 on Nginx 1.25.3 official stable base image, and latest stable Core Rule Set 3.3.5*
+   * [openresty-alpine-fat](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/openresty/Dockerfile-alpine)
+* Apache httpd – *last stable ModSecurity v2 on Apache 2.4.58 official stable base image, and latest stable Core Rule Set 3.3.5*
+   * [apache](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile)
+   * [apache-alpine](https://github.com/coreruleset/modsecurity-crs-docker/blob/master/apache/Dockerfile-alpine)
+
+### Notes regarding Openresty version of this image
+
+We currently only provide a version of the Openresty image based on **Alpine Linux**. The Dockerfile for Openresty resides in the [docker-openresty repository](https://github.com/openresty/docker-openresty/blob/master/alpine/Dockerfile.fat).
 
 ## Supported architectures
 
-We added the [docker buildx](https://github.com/docker/buildx) support to our docker builds so additional architectures are supported now. As we create our containers based on the official apache and nginx ones, we can only support the architectures they support.
+Our builds are based on the official Apache httpd, nginx and Openresty images, which means we can only support the architectures they support.
 
-There is a new file `docker-bake.hcl` used for this purpose. To build for new platforms, just use this example:
+We currently provide images for the following architectures:
 
-```bash
-docker buildx create --use --platform linux/amd64,linux/i386,linux/arm64,linux/arm/v7
-docker buildx bake -f docker-bake.hcl
-```
+* linux/amd64
+* linux/arm/v7
+* linux/arm64/v8
+* linux/i386
 
-We require a version of `buildx` >= v0.9.1. [Visit the official documentation](https://docs.docker.com/build/buildx/install/) for instructions on installing and upgrading `buildx`. You can check which version you have using:
+### Building
+
+We require a version of `buildx` >= v0.9.1. [Visit the official documentation](https://docs.docker.com/build/architecture/#install-buildx) for instructions on installing and upgrading `buildx`. You can check which version you have using:
 
 ```bash
 docker buildx version
@@ -54,22 +83,30 @@ If you want to see the targets of the build, use:
 docker buildx bake -f ./docker-bake.hcl --print
 ```
 
-We are building now for these architectures:
-
-* linux/amd64
-* linux/arm/v7
-* linux/arm64/v8
-* linux/i386
+To build for any platforms of your choosing, just use this example:
 
-You can find additional examples on how to use `buildx` in this repository's GitHub act
-We added the [docker buildx](https://github.com/docker/buildx) support to our docker builds so additional architectures are supported now. As we create our containers based on the official apache and nginx ones, we can only support the architectures they support.
+```bash
+docker buildx create --use --platform linux/amd64,linux/i386,linux/arm64,linux/arm/v7
+docker buildx bake -f docker-bake.hcl
+```
 
 To build a specific target for a single platform only (replace target and platform strings in the example with the your choices):
 
 ```bash
 docker buildx bake -f docker-bake.hcl --set "*.platform=linux/amd64" nginx-alpine
 ```
 
+### Notes regarding Openresty version of the image
+
+Openresty image builds currently support only these architectures:
+
+* linux/amd64
+* linux/arm64
+
+## Container Health Checks
+
+🆕 We add healthchecks to the images, so that containers return HTTP status code 200 from the `/healthz` endpoint. When a container has a healthcheck specified, it has a _health status_ in addition to its normal status. This status is initially `starting`. Whenever a health check passes, it becomes `healthy` (whatever state it was previously in). After a certain number of consecutive failures, it becomes `unhealthy`. See <https://docs.docker.com/engine/reference/builder/#healthcheck> for more information.
+
 ## CRS Versions
 
 > Hey, I used some specific git version with the containers? What happened?
@@ -218,6 +255,10 @@ Note: Apache access and metric logs can be disabled by exporting the `nologging=
 | TIMEOUT  | Number of seconds for a keep-alive client connection to stay open on the server side (Default: `60s`) |
 | WORKER_CONNECTIONS  | Maximum number of simultaneous connections that can be opened by a worker process (Default: `1024`) |
 
+### Openresty ENV Variables
+
+Openresty uses the same environment variables as the nginx version.
+
 ### ModSecurity ENV Variables
 
 All these variables impact in configuration directives in the modsecurity engine running inside the container. The [reference manual](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)) has the extended documentation, and for your reference we list the specific directive we change when you modify the ENV variables for the container.
@@ -259,8 +300,6 @@ All these variables impact in configuration directives in the modsecurity engine
 
 | Name     | Description|
 | -------- | ------------------------------------------------------------------- |
-| USER | A string value indicating the name (or #number) of the user to run httpd or nginx as (Default: `www-data` (httpd), `nginx` (nginx)) |
-| GROUP | A string value indicating the name (or #number) of the group to run httpd as (Default: `www-data`) |
 | BACKEND  | The backend address (and optional port) of the backend server. (Default: the container's default router, port 81) (Examples: 192.0.2.2, 192.0.2.2:80, <http://172.17.0.1:8000>) |
 
 ### CRS specific
@@ -359,8 +398,6 @@ docker run -dti -p 80:80 --rm \
    -e TIMEOUT=60 \
    -e LOGLEVEL=warn \
    -e ERRORLOG='/proc/self/fd/2' \
-   -e USER=daemon \
-   -e GROUP=daemon \
    -e SERVER_ADMIN=root@localhost \
    -e SERVER_NAME=localhost \
    -e PORT=80 \

diff --git a/apache/Dockerfile b/apache/Dockerfile
@@ -1,9 +1,9 @@
-ARG APACHE_VERSION=2.4.58
+ARG HTTPD_VERSION="n/a"
 
-FROM httpd:${APACHE_VERSION} as build
+FROM httpd:${HTTPD_VERSION} as build
 
-ARG MODSEC_VERSION=2.9.7 \
-    LUA_VERSION=5.3
+ARG MODSEC2_VERSION="n/a"
+ARG LUA_VERSION="n/a"
 
 RUN set -eux; \
     echo 'debconf debconf/frontend select Noninteractive' | debconf-set-selections; \
@@ -27,16 +27,16 @@ RUN set -eux; \
         wget
 
 RUN set -eux; \
-    wget --quiet https://github.com/SpiderLabs/ModSecurity/archive/refs/tags/v${MODSEC_VERSION}.tar.gz; \
-    tar -zxvf v${MODSEC_VERSION}.tar.gz; \
-    cd ModSecurity-${MODSEC_VERSION}; \
+    wget --quiet https://github.com/SpiderLabs/ModSecurity/archive/refs/tags/v${MODSEC2_VERSION}.tar.gz; \
+    tar -zxvf v${MODSEC2_VERSION}.tar.gz; \
+    cd ModSecurity-${MODSEC2_VERSION}; \
     ./autogen.sh; \
     ./configure --with-yajl --with-ssdeep; \
     make; \
     make install; \
     make clean
 
-FROM httpd:${APACHE_VERSION} as crs_release
+FROM httpd:${HTTPD_VERSION} as crs_release
 
 ARG CRS_RELEASE
 
@@ -56,10 +56,10 @@ RUN set -eux; \
     rm -f v${CRS_RELEASE}.tar.gz coreruleset-${CRS_RELEASE}.tar.gz.asc; \
     mv -v /opt/owasp-crs/crs-setup.conf.example /opt/owasp-crs/crs-setup.conf
 
-FROM httpd:${APACHE_VERSION}
+FROM httpd:${HTTPD_VERSION}
 
-ARG MODSEC_VERSION=2.9.7 \
-    LUA_VERSION=5.3
+ARG MODSEC2_VERSION
+ARG LUA_VERSION
 
 LABEL maintainer="Felipe Zipitria <felipe.zipitria@owasp.org>"
 
@@ -134,17 +134,15 @@ ENV APACHE_ALWAYS_TLS_REDIRECT=off \
     SSL_USE_STAPLING=On \
     TIMEOUT=60 \
     WORKER_CONNECTIONS=400 \
-    USER=www-data \
-    GROUP=www-data \
     # CRS specific variables
     PARANOIA=1 \
     ANOMALY_INBOUND=5 \
     ANOMALY_OUTBOUND=4 \
     BLOCKING_PARANOIA=1
 
 COPY --from=build /usr/local/apache2/modules/mod_security2.so                  /usr/local/apache2/modules/mod_security2.so
-COPY --from=build /usr/local/apache2/ModSecurity-${MODSEC_VERSION}/modsecurity.conf-recommended  /etc/modsecurity.d/modsecurity.conf
-COPY --from=build /usr/local/apache2/ModSecurity-${MODSEC_VERSION}/unicode.mapping               /etc/modsecurity.d/unicode.mapping
+COPY --from=build /usr/local/apache2/ModSecurity-${MODSEC2_VERSION}/modsecurity.conf-recommended  /etc/modsecurity.d/modsecurity.conf
+COPY --from=build /usr/local/apache2/ModSecurity-${MODSEC2_VERSION}/unicode.mapping               /etc/modsecurity.d/unicode.mapping
 COPY --from=crs_release /opt/owasp-crs /opt/owasp-crs
 COPY src/etc/modsecurity.d/*.conf /etc/modsecurity.d/
 COPY src/bin/* /usr/local/bin/