16

I'm setting up a GitLab server in my company and now I'm adding GitLab CI to it.

Before start this task I'd like to understand if there are any disadvantages running my runners on the same server used by GitLab and GitLab CI.

I've read that there are security concerns but we use it only internally so I don't think this could be a problem.

Am I missing something?

Rory Hunter
  • 1,737
  • 9
  • 15
Fez Vrasta
  • 556
  • 1
  • 5
  • 12

2 Answers2

13

Imagine the following situations:

  • An internal developer wants to harm the company (because considers being underpaid, because his boss sleeps with his wife; the reason doesn't matter) He commits a unit test which, when ran, instead of testing the application, searches for GitLab repository and erases it. At the next commit, surprise, all source code of the project is lost (but you do backups and you tested them, right?)

  • Or the same developer notices that backups of the repository are configured on the same machine. He changes this configuration through a unit test, so that the backup contains now a different repository, and waits for a month—the time the backups are kept. Now that all the backups are corrupted, he can commit his unit test which wipes out the source code from the server.

  • Or an intern wants to sell the source code to the competition. You've carefully configured the access, limiting it to only what he needs for his work. At the same time, he has unlimited access to the repository itself through the unit tests, being able to do the complete dump.

Unless unit tests are run in a context of limited permissions and can't access anything beyond the directories and files they need for the tests, mixing CI server with the server which keeps your repository is indeed dangerous.

Another issue is that version control server is expected to be fast. CI server installed on the same machine may slow the commits.

Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513
  • 9
    We are 3 developers... if someone of us wanna harm the company he can do that in thousand of ways =( ... So the only problem would be the slow performances, but if I use a nice machine I should not have big troubles, right? Thanks! – Fez Vrasta Apr 28 '14 at 10:28
  • ps: what about chroot? Can't be used to make the process safe? – Fez Vrasta Apr 28 '14 at 10:34
  • 4
    @FezVrasta: if security is not a concern in your case, nor are the performances, the only benefit to have separate machines that I can see is the future scalability. But frankly, doing changes before scalability problems appear looks similar to premature optimization. – Arseni Mourzenko Apr 28 '14 at 10:44
  • @FezVrasta: *"what about chroot? Can't be used to make the process safe?"* - I don't have enough skills in Unix security to answer that question. – Arseni Mourzenko Apr 28 '14 at 10:45
  • Docker can make the process safe and containerized – Heng Ye Jun 05 '20 at 21:09
0

Given that there is no central “all knowing” server for git this is not a bad as it would be with some other source code control systems.

Provided there is an automatic syk of the git server off-site to anther git server (that is tested) I would not be concerned about this setup in a small company.

Ideally I would like to see the developers push their changes to the offset server git server, then the CI server to pull the charges from the offset server – that way the offsite server is tested when every check in is done.

If the developers then always did their pull from the onsite server to save time, that is not an issue.

Ian
  • 4,594
  • 18
  • 28
  • 1
    if I need 2 servers... why should I not just run runners on the 2nd server? – Fez Vrasta Apr 28 '14 at 11:41
  • @FezVrasta, the "**offsite** server" can be anyone that will sell you git hosting, it does not have to be a server you own. Also as it is over the internet doing a pull from it will be slow. – Ian Apr 28 '14 at 12:40
  • 1
    I'm setting up it for my company, we use our own servers... – Fez Vrasta Apr 28 '14 at 12:42