Configure gitlab-runner related docker images to be scanned for vulnerabilities
What
As part of the gitlab-runner
project, we produce A LOT of docker images in the gitlab-runner
repo itself, and in other related repos (see https://gitlab.com/gitlab-com/Product/-/issues/4963#note_1139652185 for complete inventory). Many (probably not all) of those images should be scanned for vulnerabilities, but only a very few of them are:
- registry.gitlab.com/gitlab-org/gitlab-runner/go-fips
- registry.gitlab.com/gitlab-org/gitlab-runner/helper-entrypoint
- registry.gitlab.com/gitlab-org/gitlab-runner/ci
- registry.gitlab.com/gitlab-org/gitlab-runner/alpine-no-root
- registry.gitlab.com/gitlab-org/gitlab-runner/alpine-entrypoint
- registry.gitlab.com/gitlab-org/gitlab-runner/alpine-entrypoint-stderr
- registry.gitlab.com/gitlab-org/gitlab-runner/apline-id-overflow
In addition to the above, the following images (at least) should also be configured to be scanned for vulnerabilities when new version are pushed to the corresponding repository: repository
- registry.gitlab.com/gitlab-org/gitlab-runner (https://gitlab.com/gitlab-org/gitlab-runner)
- ubi-fips
- ubi-fips-bleeding
- latest == ubuntu
- alpine == alpine3.15
alpine3.14alpine3.13alpine3.12
- registry.gitlab.com/gitlab-org/gitlab-runner/gitlab-runner-helper (https://gitlab.com/gitlab-org/gitlab-runner)
alpine3.13-x86_64-@releasealpine3.13-arm-@releasealpine3.13-arm64-@releasealpine3.13-s390x-@releasealpine3.13-ppc64le-@release- alpine3.15-x86_64-@release
- alpine3.15-arm-@release
- alpine3.15-arm64-@release
- alpine3.15-s390x-@release
- alpine3.15-ppc64le-@release
- alpine-latest-x86_64-@release
- alpine-latest-arm-@release
- alpine-latest-arm64-@release
- alpine-latest-s390x-@release
- alpine-latest-ppc64le-@release
- ubuntu-x86_64-@release
- ubuntu-arm-@release
- ubuntu-arm64-@release
- ubuntu-s390x-@release
- ubuntu-ppc64le-@release
- ubi-fips-latest-x86_64-@release
ubi-fips-latest-arm-@releaseubi-fips-latest-arm64-@releaseubi-fips-latest-s390x-@releaseubi-fips-latest-ppc64le-@release
- registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-ocp (https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images)
- registry.gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images/gitlab-runner-helper-ocp (https://gitlab.com/gitlab-org/ci-cd/gitlab-runner-ubi-images)
- registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator (https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator)
- registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator-catalog-source (https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator)
- registry.gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/gitlab-runner-operator-bundle (https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator)
Why
Proactive FedRAMP compliance, so we have fewer Forced Prioritization issues... forced on us.
Where
The project responsible for performing the scans is https://gitlab.com/gitlab-com/gl-security/appsec/container-scanners. How the scan works and what it consists of isn't really of concern here, but the project has more info.
How
Triggering a scan of a container is straight forward:
curl -X POST --form token="${CONTAINER_SCANNING_PIPELINE_TRIGGER_TOKEN}" \
--form ref=master \
--form "variables[IMAGES]= ${BUILD_IMAGE}" \
https://gitlab.com/api/v4/projects/16505542/trigger/pipeline
And is done here in gitlab-runner
OR as described here. For this issue, we want to add more images to the gitlab-runner
project to trigger a scan, and similar machinery in the gitlab-runner-ubi-images
and gitlab-runner-operator
projects (at least)