Gitlab.com CI for Private Projects

4
votes

Summary: We have a concern based on one piece of documentation regarding Gitlab.com CI for private projects

Note: This is in reference to Gitlab.com (and not a self-hosted gitlab)

Concern: We came across this link, https://docs.gitlab.com/ee/ci/runners/#be-careful-with-sensitive-information

My Interpretation: its not advisable to build private projects in Default Gitlab CI Runners

  • Is the interpretation valid? and to what extent a concern?
  • What do you think will be the best practice for this?

Question:

  • Is it fine to use Gitlab.com Shared Runners for CI in Private Projects?

Our Solution: IF and only IF we need an alternative (POC for this was successfully implemented)

  • We created a EC2 Instance (a private box)

  • Installed Gitlab Runner to the box

  • Connected EC2 Instance to Gitlab

  • Disabled Shared Runner from Project setting

  • On CI run, it successfully sends the request to our EC2 instance

https://gitlab.com/gitlab-org/gitlab/-/issues/215677

1
continuous-integrationgitlabgitlab-cigitlab-ci-runner

1 Answers

0
votes

Short: My interpretation was wrong. Gitlab.com is fully safe. Quoted Doc is NOT for this use-case.

Read Response from Gitlab.com: https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25468#note_333854812

Quote of response:

The Shared Runners on GitLab.com are isolated VM's that are provisioned for each CI job and removed after job execution. This is documented here. The documentation that you reference is actually referring to the situation where as a user you are now setting up and managing your own Runners. This is actually what you have done in the Our Solution section. So the security concern is that on your EC2 instance, if the Runner is configured to use the Shell executor for example, then any user in your organization that can execute CI jobs on the Runner on that EC2 instance is now able to execute a script which has full access to the filesystem on the EC2 instance. So this is why on GitLab.com we always create new isolated VM's for each job.