No Trigger Job Arm64 Image Build (!1312) · Merge requests · Iron Bank / ironbank-pipeline

Jeffrey Wuebbles requested to merge no-trigger-arm64 into master Mar 12, 2024

Description

The pipeline runs without calling trigger.
A single pipeline may build the following architectures:
- amd64
- arm64
- amd64 & arm64

Create the CI/CD variable ENABLE_MULTIARCH and assign it any value to enable building arm64 images. This variable's adds an extra layer of security to prevent unintended multi-arch builds.
The arm64 image uses the Dockerfile.arm64 as its Dockerfile. Therefor the Dockerfile.arm64 must be present in the project to build an arm64 image.
The resources listed in the hardening-manifest must have unique names or they will overwrite each other while they are imported. All imported resources that are not images are available both architecture's build stage. Images passed from the import-artifacts job as tars files are loaded into the build context with the following logic. I would recommend appending ".arm64" to an image being imported into an arm64 image build. Here's an example tag for importing the arm64 ubi9 base image, "registry.access.redhat.com/ubi9:9.3.arm64".
- For arm64 image resources: if (os.environ["CI_JOB_NAME"] == "build-arm64" and "arm64" in resource_file_obj.name):
- For amd64 image resources: if (os.environ["CI_JOB_NAME"] == "build-amd64" and "arm64" not in resource_file_obj.name):

An amd64 only image build uses the tag provided in the hardening manifest during the vat, upload-to-s3, and harbor job ensuring compatibility with existing projects. During a multi-arch build the tag listed in hardening-manifest is sent to vat and upload-to-s3 still, but the image will be available on harbor with the architecture appended. This is explained more below.
The arm64 image will send its information to vat and upload-to-s3 with the architecture appended. For example the tag to find the arm64 image in vat will be 1.0.0-arm64.
During a multi-arch build a manifest list is created with both images included in it. The manifest list will have the tag provided in the hardening manifest. Both images listed by the manifest list will have the same tag as the manifest list with the architecture appended.
- manifest-list tag: 1.0.0
  - amd64 image tag: 1.0.0-amd64
  - arm64 image tag: 1.0.0-arm64
After merging this MR this repo's pipeline will only be looking in the pipeline1 repo for linting, trufflehog, etc.
Manifest lists for gitlab-runner-helper (ECR), istio/proxyv2 (ECR), pipeline-runner (Harbor) will need to be maintained so images can properly be pulled.
VAT findings for arm64 populate with justifications made for the amd64 image for vulnerabilities they have in common, so an arm64 image does not have to be justified from scratch.

Edited Apr 02, 2024 by Jeffrey Wuebbles