Search code examples
gitlabcontinuous-integrationgitlab-cicicd

Can a GitLab CI job be bound to a user's ID?

GitLab CI allows adding rules to jobs that will define when exactly the processing of a specific job will be triggered, e.g. only if a push to a specific branch takes place.

I would like to know if there is a way to also use the user's ID.

REASON: This comes from a concern regarding a license for a software that is needed for a project but the license is bound to a specific person (with the respective GitLab user account). If such a rule is added, only the user, who is a license holder, will be able to execute the job thus not getting into any conflict with the license agreement (which is very vague and sloppy as usual). The runner that executes the job and has access to the licensed software will also be restricted. If this setup is not possible, it will create a lot of extra work (downloading and sending the code, building it and then uploading it somewhere, so that it can be used).

Solution

  • There are a few predefined variables you can use in rules: to check the user:

    • GITLAB_USER_EMAIL / GITLAB_USER_ID which refers to the user that triggered the pipeline (or in the case of manual jobs, the user that triggered the job)
    • CI_COMMIT_AUTHOR refers to the email of the commit author in git. Keep in mind, unless you enforce GPG signing, users can push commits that use any arbitrary author.

    For example, you may do something like:

    rules:
  - if: $GITLAB_USER_ID == "123"

    But keep in mind that GitLab CI rules: are not meant to be used as security measures and anyone who can change the CI YAML can simply remove those restrictions or create other jobs or modify source code in the repo that do the same script actions without the associated checks on user ID. rules: also only apply when the pipeline is created not necessarily when manual jobs are run. These variables can also be overridden.

    Some other strategies you might use:

    Protected Environments

    If you have a GitLab Premium or Ultimate subscription, you might consider using the protected environments feature to select what users are allowed to trigger a "deploy" job for that environment.

    Runner configuration

    Since the software is installed on your runner, you could also consider using a script to check the user ID variables or an ID token instead. For example you may configure your runner to have a pre_build_script or pre_get_sources configuration that performs this check.

    Whether or not any of these things satisfy your legal obligations under the software licensing agreement is another story.