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 controlnever 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.
- 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.
- 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.
- 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?