Should I set up a shared account in our CI infrastructure to make it easier to use?

My team uses CI infrastructure. When a developer first sets up a build he must enter his source control credentials so that the server can access the code. Thus the build is "tied" to a particular developer. I personally like this--I think each build should have a maintainer and that the maintainer's credentials should be used.

Occasionally things break because of account permissions issues, such as when a developer changes his password. I think this is because we don't manage user accounts well.

Some team members think that we should have a shared source control account to prevent this kind of problem. All builds could use the same shared account for accessing source control.

I am opposed to this because of the security implication. Since the shared account's credentials would be common knowledge, anyone could use it with no traceability to a person. We would not be able to limit access to certain parts of source control to certain individuals.

Would a common source control account for running CI builds actually be a problem? How do other small software shops manage this?

  • 2
    How would you like it if the build that creates your official releases breaks because the password of the user that created it has expired and that user is not available for a longer time (long holiday, off sick, etc.) Commented Dec 2, 2016 at 14:54
  • I'd be more afraid of the security implications of storing developer's credentials in plain text on the CI server. Just imagine what a hacker or malicious coworker could do with that! It's good that you're thinking about security, but you should be clear about what you are defending against. And if there is top-secret code that may not be seen by uninitiated developers, why is there a single build system for top-secret and unclassified code?
    – amon
    Commented Dec 2, 2016 at 14:57

1 Answer 1


A single shared account for driving the CI infrastructure offers the great advantage of consistency, which is key to the CI effectiveness. Much more difficult to manage with a multitude of accounts.

You could restrict access to the shared account to just a certain group of trusted individuals - for example only (some) members of the DevOps team. This can be done in a safe/secure manner - explicit sudo permissions or SSH public keys, for example.

The drawback would be that not all ordinary developers could setup CI builds. IMHO that's not necessarily a bad thing - a proper CI setup is not a trivial matter, I'd rather leave that to knowledgeable individuals than debug incorrectly setup CI environments.

  • Having a common and secure set up doesn't mean that the responsibility for setting up the build can't be shared. Simply store the credentials/key in an environment variable.
    – RubberDuck
    Commented Dec 2, 2016 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.