This repository contains Dockerfiles for Aquia Base Docker Images.
[2024-10-24] This repository is a work in progress. Not all images referenced below are currently available.
Images are considered hardened when they do not contain fixed CVE vulnerabilities of the following severities: CRITICAL, HIGH, MEDIUM. They are based on wolfi-base from Chainguard. We use Renovate to automatically update each of these base images to the most recently published image (latest).
- NodeJS
- Python
- OpenJDK-17, with Maven 3.9.5
- Wolfi Base
- Wolfi Base with FIPS (beta*)
- nginx
The images are tagged with Semantic Versioning and also with the installed language's major (i.e. python-base:3) and major + minor (i.e. python-base:3.12) versions (currently implemented for Python, Node, openJDK).
If you want to ensure that your image's installed language is not updated to a potentially non-backwards-compatible version, you can pin the version of the image you are using to the specific version of the language you want - i.e. python-base:3.12.
Note, however, that due to the limitations of our using Chainguard's free tier, we can only keep the latest wolfi-base image up-to-date, so once wolfi-base moves to python 3.13 for example, the python-base:3.12 will no longer be automatically patched by our workflows.
On the other hand, pinning your image to python-base:3 for exammple, allows you to receive all Python 3 security updates, but it will also force you to upgrade to the next minor version whenever wolfi-base is updated to that version of Python.
Both choices have tradeoffs and is a decision you need to make based on your project's needs.
The non-language-specific images, such as the nginx-base and wolfi-base can be pinned to :latest as they are unlikely to bring backwards-incompatible changes to your workloads.
export CR_PAT=YOUR_TOKEN
$ echo $CR_PAT | docker login ghcr.io -u USERNAME --password-stdin
> Login SucceededAll currently available images are listed here.
To use an image in your project, you can use the following snippet:
FROM ghcr.io/aquia-inc/base-docker-images/<docker-image-name>:<semver tag>Anyone can pull the image locally with their Github personal access token.
The beta images are tested within limited scope and are generally stable but not recommended for production use without thorough testing in lower environments. We encourage you to use them for testing and development and provide feedback to us to help us get them to GA. If any bugs or unexpected behaviors are encountered, please open an issue using the BUG_REPORT template in this repository with enough detail to reproduce the issue.
The image built from the Dockerfile.fips-base includes FIPS-enabled OpenSSL and the Dockerfile shows an example of how to use it in the Example Stage 2 section that should be modified to your workload's specific needs.
If you are using the nginx image provided in this repository, you should also use the nginx.conf file in this repository if you need to make any changes to it. In most cases, you should not need to make any changes to the nginx configuration as it is already matching configuration set up in the container.
The nginx server in the nginx image should be run as user nginx for security reasons, but the server can also be started as user root in situations where nginx needs to bind to ports < 1025, i.e. 0.0.0.0:80. In those scenarios nginx parent process will be started as root, then drop privileges when starting worker processes by switching to user nginx.
This mode of operation reqires that the following stanza at the top of nginx.conf is uncommented and looks as follows:
user nginx;Running nginx unprivileged, on ports > 1024:
PID USER TIME COMMAND
1 nginx 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -e /dev/stderr -g daemon off;
7 nginx 0:00 nginx: worker process
8 nginx 0:00 nginx: worker process
9 nginx 0:00 nginx: worker process
10 nginx 0:00 nginx: worker process
11 nginx 0:00 /bin/sh
232 nginx 0:00 ps aux
Running on lower ports as user root and worker processes running as user nginx after starting the container, will look similar to the below:
PID USER TIME COMMAND
1 root 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -e /dev/stderr -g daemon off;
8 nginx 0:00 nginx: worker process
9 nginx 0:00 nginx: worker process
10 nginx 0:00 nginx: worker process
11 nginx 0:00 nginx: worker process
12 root 0:00 /bin/sh
18 root 0:00 ps aux
Please see the examples directory for an example nginx workload configuration file and the corresponding Dockerfile.
PR to main with new Dockerfile in format Dockerfile.<image-name>. This will build your Docker image with semver tag 0.0.1.
- Merge PR to main.
- Workflow will diff which Dockerfiles changed and create release tags for them.
- Workflow triggered by creation of new release tag will build new Docker image, incrementing the patch version and setting it to
latest.
You must have permissions to push tags to this repository.
-
Make sure you are on the commit that you want to create the tag from.
-
Create tag in the format:
git tag -a release/<docker-image-name>/vX.X.X -m "release description"
-
Push tag:
git push origin <tag-name>
For example:
git checkout main
git pull
git tag -a release/python-base/v0.0.2 -m "Rebuild to pickup fix for CVE-2023-43804 urllib3 MEDIUM"
git push origin release/python-base/v0.0.2-
Any workflows that we want to trigger other workflows cannot use the default GITHUB_TOKEN, so we are using a Deploy Key for the Create Release Tag workflow. A Deploy Key is preferable to a Personal Access Token, since it can be repository-scoped and not tied to a specific user.
-
The Create Release Tag workflow is triggered by the Create Release Tag workflow.