Shell Executors Should Support SetUID Capabilities
Description
Currently the gitlab-runner daemon can be run as any user, but all jobs will then subsequently be run as that user as well. I believe it should be possible to allow jobs to be run as the user that initiates them. This would allow higher security environments to better control which jobs can be run by specific users or groups on their infrastructure.
Proposal
I propose that we build SetUID runners, which leverage user accounts on the CI system to ensure only users with appropriate access can run specific CI jobs. All SetUID features will be controlled via parameters in the runner's config.toml. The suggested options would be:
- SetUID:
boolean
- SetUIDDataDir:
string
- SetUIDUserWhitelist:
[]string
- SetUIDUserBlacklist:
[]string
- SetUIDGroupWhitelist:
[]string
- SetUIDGroupBlacklist:
[]string
These options would allow SetUID to be toggled via the config file, and off by default. Additionally, the SetUID specific data directory would allow a user to specify their own location for builds, including user home directories. The whitelist/blacklist features would allow for restricting access to specific users in groups using industry set standards for precedence.
A strict validation process will also happen before the Runner processes are forked as the specific user which will validate a users existence on the CI system and will also validate that the appropriate directory structure exists for that user's jobs.
Links to related issues and merge requests / references
A merge request will be coming with the proposed solution from this repository: https://gitlab.com/onyxpoint/gitlab-runner/commit/5157700ac1ae2693b0d2c81b0c44e1d4f65b8afe
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.