Gitlab shared runner safety doubts

0
votes

My plan is to use GitLab pipeline to build maven application and deploy it to AWS Elastic Beanstalk. During research I found this page.

If you are using gitlab.com there is a shared runner by default which you can use. Note this runner is shared with other users that means it may mean you have to wait in a que until another user’s build has completed, cannot scale and also mean that you may not use the shared runner builds including variables which may be exposed in a shared runner.

I'm confused. All builds are done inside the docker, so as far as I understand, there is no way to see my code, credentials to deploy or built artifacts. So is it safe to use shared runner in my case? I just want to make sure that my code, credentials / keys to deploy and build jar is safe.

Exaple code:

development:
  type: deploy
  environment: production
  script:
  - mkdir ~/.aws/
  - touch ~/.aws/credentials
  - printf "[eb-cli]\naws_access_key_id = %s\naws_secret_access_key = %s\n" "$AWS_ACCESS_KEY_ID" "$AWS_SECRET_ACCESS_KEY" >> ~/.aws/credentials
  - touch ~/.aws/config
  - printf "[profile eb-cli]\nregion=ap-southeast-1\noutput=json" >> ~/.aws/config
  - eb deploy funwitheb-production
  only:
  - master
2
amazon-web-servicesgitlabgitlab-ciamazon-elastic-beanstalkgitlab-ci-runner

2 Answers

1
votes

I can't find any solid Gitlab-docs based proof after searching for a while but I've also never made it to actually read other user's variables while executing a job on a shared runner.

I also can't find any GitLab issues related to this (ie. someone "accidentally" seeing someone else's vars) so security/privacy-wise it looks fine.

0
votes

I've sent email to author of article. Article is from 2016. This information is not up to date. So probably this is not problem anymore. Here is more information: https://gitlab.com/gitlab-org/gitlab-runner/blob/master/docs/security/index.md

Docker can be considered safe when run in non-privileged mode. To make such setup more secure it's advised to run jobs as user (non-root) in Docker containers with disabled sudo or dropped SETUID and SETGID capabilities.