3

This seems like an odd and simple question, but I'm trying to get my head around the principle of "never check a private key into version control".

I'm trying to build a startup of sorts, where clients have private/separate deployments based on a common platform.

To manage all of this the code for each client will be stored in a private GitLab repository (stored on GitLab.com), and will then be deployed to Amazon Web Services to handle deployment and scalability. I'm hoping to scale this up to a large number of clients so automation is key.

I've come up with a number of scenarios each with pros/cons but all fall astray of the "no private keys" in repos problem.

  1. Use GitLab pipelines/runners to test the code and then deploy to production... except to do this the GitLab runner will require access to AWS which requires a private key. And the key will be in all client repos.
  2. Make each AWS deployment periodically poll for updates, download from the GitLab repo and install the updates... except to do this AWS script will require access to GitLab which requires a private key.
  3. Make a management system which handles deployments of code from GitLab to AWS... but still requires private keys to both. Fortunately the keys are only in one place.

Assuming the GitLab repository is private and only accessible by myself (or eventually trusted employees) how do you go about actually having continuous integration between private services?

Improve this question
3
  • HSM, Cloud-HSM, Smart card... ways to protect private keys are well documented.
    – Little Code
    Commented Jun 14, 2016 at 11:07
  • I know its a basic question, but a lot of my research for "where to store private keys" literally turned up "don't store private keys in code repositories" without much more information.
    – user27727
    Commented Jun 14, 2016 at 12:40
  • You haven't stated what types of keys you're using (RSA or fixed strings), but seeing as your plan is cloud deployment, then you might as well use cloud as a solution. Although StackExchange is not the place for "product recommendations", I will give you a big hint to look in the direction of Azure Keyvault, which is their cloud-HSM solution, and you can use it for both types of "keys" (RSA private-keys and what Microsoft call "secrets", i.e. strings). Amazon might do one too in AWS...
    – Little Code
    Commented Jun 14, 2016 at 14:33

1 Answer 1

Reset to default
1

What you're facing here is the problem of secret management. It's kind of a big question mark in cloud architecture. The advice to never store secrets in version control is sound. It's just kind of hard to make that happen sometimes.

Some ways forward:

  • Gitlab has a notion of secrets. This is a way for the CI server to maintain keys in a way where they're not in the repo but are available to the deployment tasks. Cloud providers also support creating restricted keys which can do only one specified task. I recommend doing that instead of using root or admin credentials.

  • There is also a notion of release keys. Keys which are specialized to a server and authorized only to pull new code for that project.

  • The major Cloud providers also offer secure secret management. It might be worth deploying around a hosted secret management system.

  • Or deploy your own secure secret store something like Hashicorp Vault for very fine-grained control of secrets.

Improve this answer

You must log in to answer this question.