Investigation: Move Code Quality job orchestration to CI template to avoid Docker-in-Docker
Problem
Code Quality currently uses Docker-in-Docker to run various analyzers. The CI template executes a docker run
that mounts the Docker API socket; that container then executes further docker run
commands and creates a gl-code-quality-report.json
file.
Docker-in-Docker is problematic for a number of reasons:
- It is a significant security issue. See, for example, Runner security documentation.
- Many Kubernetes platforms are deprecating Docker, matching upstream Kubernetes's deprecation of the Docker shim.
- It prevents use of OpenShift (which has used CRI-O for a long time (see Support CodeQuality with Auto DevOps on OpenShift (#276081 - closed)).
Dropping the Docker-in-Docker requirement has long been requested for a variety of reasons (see, e.g., Run codequality on shared runners without docke... (#9784 - closed)).
Note: This was previously investigated in #267930 (closed).
Scope of this issue
Assess the feasibility of moving the Docker-in-Docker orchestration to a CI template akin to the strategy used in Static Application Security Testing (SAST).
Scope of delivery
The replacement template can have a limited scope compared to the current scope of the feature. For example, if needed:
- The replacement can cover more commonly used languages as a first iteration, and omit less commonly used languages.
- The template can rely on support for processing multiple Code Quality reports, even though support for handling multiple reports is limited in certain UI features (see
artifacts:reports:codequality
documentation. - The template can reference upstream (Docker Hub) images directly. Ideally we would support the
CODECLIMATE_PREFIX
as before, but this doesn't strictly have to be in the MVC.
The template should be accessible at an alternate location. Those who are happily using the existing template should not be disrupted.