Define allowed runner version matrix
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Instance administrators are allowed to define which version(s) of the GitLab runner are allowed to connect to the GitLab instance.
Problem to solve
In an effort to provide better chargeback/cost allocation details, our company has elected not to provide instance-wide shared GitLab Runner instances. Instead, each group/project wishing to make use of the CI/CD subsystem is allowed/encouraged to deploy their own runner instances. The downside to this policy is that not all runner owners actively patch their runners to the latest version.
Proposal
For version scope notation, please see the interval notation section of the SemVer versioning blog article. By default, the set of allowed versions is (-inf,+inf).
As part of the runner configuration (at the instance, project or group level), a user with appropriate permissions (instance administrator, group owner, or project maintainer) may set an allowed runner version matrix. Once a matrix is set, several things will happen.
- If a registered runner reports a version that is outside the matrix for the scope at which it is registered, the GitLab instance will report it as being in a state like 'patch needed'.
- When attempting to schedule a CI/CD job, only those runners which fall within the matrix for that project will be considered for scheduling.
- In the CI/CD settings for a project, those associated runners which fall outside the matrix will be marked with a distinctive icon (such as an X) to indicate this condition. This icon should be different than the icon used to indicate an offline runner (no entry circle).
- If the CI/CD subsystem wishes to schedule a job, but all available runners fall outside the matrix, the pipeline/job will be placed in a state like 'no runners', and a notification event reporting the lack of available runners will occur as if the job had failed.
- When a runner attempts to register, the reported version of the runner is compared against the matrix for the scope specified by the registration token. If the version of the runner falls outside the matrix, the registration process will fail.
If the allowed version matrix can be set at multiple scopes, only runners with those versions meeting the intersection of the scopes will be used for builds.
- Suppose that the group owner has set a scope of
[14.5,+inf), but the maintainer of a project within the group has set a scope of[14.4,+inf). The effective matrix for that project would be[14.5,+inf)(as the group is more restrictive than the project). - Suppose that the instance administrator has set a scope of
[14.3.4,14.4),[14.4.2,14.5),[14.5.2,+inf)(in response to the December 10th advisory), and the group owner has set a scope of[14.4,+inf)(because they require functionality introduced in the 14.4 release). The effective matrix for this group or project would be[14.4.2,14.5),[14.5.2,+inf) - Suppose that the instance administrator has set a scope of
[14.3.4,14.4),[14.4.2,14.5),[14.5.2,+inf), and the group or project owner has set a scope of[-inf,14.3)(because they require functionality removed in the 14.3 release). This would result in an empty set and the no runners fault outlined above.
Intended users
- Alex wishes to ensure that groups/projects hosting their own GitLab runners aren't using a version of the runner with a major security vulnerability.
- Devon wishes to leverage functionality introduced in (or has templates using functionality removed in) a given version of the GitLab runner.