Support builds for different architectures including arm64

[valentijnscholten]

Description

Currently Defect Dojo base images are pinned to the manifest digest of lindex/amd64 images.
This prevents users or systems from building on/for other architectures such as linux/arm64.

This PR changes this into using index digests. These digests do not point to a single linux/amd64 image, but to the collection of images for all architectures.

I couldn't find a good page where this is explained, so I asked ChatGPT:

In Docker, especially when dealing with multi-architecture (multi-arch) images, it's essential to understand the distinction between an image's manifest digest and the index (or manifest list) digest.

Manifest Digest: Each Docker image has a manifest that describes its properties, including its layers, size, and configuration. The digest is a unique identifier (a SHA256 hash) of this manifest. When you pull an image using its digest, you're ensured to retrieve the exact same image every time, regardless of tags.
STACK OVERFLOW

Index (Manifest List) Digest: For multi-arch images, Docker uses a manifest list (also known as an image index) to reference multiple image manifests, each tailored for a specific architecture or operating system. The manifest list itself has a digest, which serves as a pointer to the appropriate image manifest based on the client's platform. Pulling an image using the manifest list's digest allows Docker to automatically select the correct image variant for your system.
GOOGLE CLOUD

In summary, while a manifest digest uniquely identifies a specific image variant, the index (manifest list) digest references a collection of image variants suitable for different platforms, facilitating seamless deployment across diverse environments.

Test results

AMD64:
The result is that when building on linux/amd64, the result is exactly the same as before. Docker will automatically pick the linux/amd64 digest from the index digest. This will be the exact same digest we previously put into the Dockerfile / docker-compose.yml files.

ARM64:
When on linux/arm64, docker will now choose linux/arm64 images for alpine, debian, postgres, etc. And will build django and nginx images for linux/arm64.

This allows users to build Defect Dojo on arm64 platforms, for example to run on the cheaper AWS Graviton instances.
It might also help users/developers on MacOS, not sure as I don't have a Mac myself.

Builds and smoke test done on AWS t4g instance.

Next steps
Next step would be for us to also build arm64 images and publish them on Docker Hub.
Currently our builds are running in GitHub actions on AMD64 runners. We could build these arm64 images using Qemu.
I've noticed that these builds are not always succeeding, mainly because compilation of Python wheels like uwsgi are failing.
I will look into running an arm64 build on a native arm64 GitHub runner image, but this requires some fiddling to get the index digest to be created correctly.

Let's start with this PR to help people get started on arm64.

Additional info
This PR also simplifies the node install process for the alpine builds. I am not aware of any need to build node from source, we can just add the alpine package.

[dryrunsecurity]

DryRun Security Summary

The code changes involve updating and improving multiple Dockerfiles in the DefectDojo application by upgrading base images, simplifying installation processes, enhancing security through non-root users and environment variables, and separating static file generation across various container configurations including nginx-alpine, django-alpine, integration-tests-debian, django-debian, and nginx-debian.

Expand for full summary

Summary:

The provided code changes are related to the Dockerfiles used in the DefectDojo application. The changes primarily focus on updating the base images, simplifying the installation process, and improving the overall security and maintainability of the Dockerfiles.

The key changes include:

1. Updating the base images to use the latest stable versions of Python, Node.js, and NGINX.
2. Simplifying the installation process by leveraging official Docker images and removing manual builds.
3. Separating the static file generation into a dedicated stage to reduce the attack surface.
4. Setting appropriate environment variables to control security-related aspects of the application deployment.
5. Ensuring the use of non-root users within the containers to improve security.

From an application security perspective, these changes are generally positive and help to improve the overall security posture of the application. The updates to the base images, the separation of concerns, and the use of environment variables and non-root users are all best practices for secure application deployment.

However, it's important to review the contents of the Dockerfiles and associated scripts carefully to ensure that no sensitive information or potential vulnerabilities are introduced. Additionally, regular monitoring and updating of the base images and dependencies are crucial to maintain the application's security over time.

Files Changed:

1. Dockerfile.nginx-alpine: The changes update the base image, simplify the Node.js installation, and separate the static file generation into a dedicated stage. These changes help to improve the security and maintainability of the NGINX-based container.
2. Dockerfile.django-alpine: The changes update the base image to a newer version, which is a routine update to ensure the application is running on the latest security patches.
3. Dockerfile.integration-tests-debian: The changes update the dependencies and install the necessary tools for running integration tests, such as Google Chrome and the Chrome driver. Security considerations include ensuring the integrity of the downloaded dependencies and reviewing the contents of the script files.
4. Dockerfile.django-debian: The changes update the base image to a newer version, which is a routine update to ensure the application is running on the latest security patches. The Dockerfile also installs various dependencies that should be reviewed for security implications.
5. Dockerfile.nginx-debian: The changes update the base image to a newer version, which is a routine update to ensure the application is running on the latest security patches. The Dockerfile also sets several environment variables that should be carefully managed and secured.

Code Analysis

We ran 9 analyzers against 5 files and 0 analyzers had findings. 9 analyzers had no findings.

View PR in the DryRun Dashboard.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[Maffooch]

I tested this locally and found good results

[mazmar]

+1 on this, we are running pure ARM kubernetes now and cannot deploy defectdojo.

[valentijnscholten]

@mazmar we'll try to publish arm64 images for releases. For now it could be interesting to see if you can build and deploy with the changes in this PR. It's based off the ’dev’ branch, so it's close to what will be 2.43.0 on Monday.

[mtesauro]

Approved

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.