Restrict which Docker images can be used in CI jobs
Problem to solve
In regulated or highly security-conscious environments, allowing the use of any accessible Docker image for CI jobs poses a potential security risk. We should allow administrators and/or group and project owners/maintainers to specify which images are explicitly permitted, and/or which are explicitly prohibited.
Intended users
This would vary in different organizations, but would likely be dictated by security teams/managers, project managers, and systems administrators in accordance with the organization's security policy.
Further details
As part of implementing these controls, we also need to include messaging and validation. Similar to the license compliance feature added in 12.3, validating images listed in .gitlab-ci.yml at the time of submitting a merge request is likely something we'd want to add.
Proposal
This would add a setting to the GitLab admin settings to whitelist and blacklist images. This should follow the same syntax as the Docker image path, defaulting to hub.docker.com in the absence of an absolute URL. Lists could support regex, to allow for grouping and wildcard syntax to simplify the list.
When a CI job is executed, the runner should check the image specified for the job in .gitlab-ci.yml against the whitelist and blacklist, and return an error if an unauthorized image is used.
As an added part of this, the .gitlab-ci.yml file can be validated during a merge request against the blacklist and whitelist to prevent unauthorized image declarations from being merged.
Permissions and Security
Permissions would vary depending on the granularity of this setting. If it should be instance-wide, then only GitLab administrators should be able to modify it. If it can be delegated to groups and projects, then it should be limited to those with Owner or Maintainer permissions.
If delegation and inheritance is supported, it would need to ensure that security isn't weakened. A Docker image couldn't be whitelisted by a project whose parent group, or the GitLab instance, has blacklisted.
Documentation
Permissions would need to change to incorporate this feature. As specified above, it's recommended to only allow GitLab administrators for instance-wide setting, and Owner and Maintainer permissions for group and project setting.
Testing
This feature would be opt-in; no behavior would change for CI without explicit modification of settings by people with sufficient permissions. Once the feature is enabled for a project/group/instance, developers would be limited in what Docker images they could use, and would need to adjust their CI pipelines accordingly.
What does success look like, and how can we measure that?
Success is measured by providing effective controls on Docker image sourcing for CI, and making these limits clear to users during CI pipeline execution and merge requests. We would also probably want to add a reporting screen to see attempts to use unauthorized images.
What is the type of buyer?
This is most likely an enterprise customer request. It ties into GitLab's security suite. This would likely be offered as an Ultimate feature.