How do Open Source projects manage continuous delivery credentials?

Question

If one has an open source project that is deployed somewhere in the cloud via a continuous delivery pipeline, how can the programmatic credentials needed for the CI/CD to deploy the application remains private?

Normally in a private project on a private repository, one could lazily place those credentials in the pipeline steps code in order for the machine to be able to deploy the application.

Don't get me wrong, there are solutions to hide credentials somewhere else than in the code. credstash is a good example as it store your creds on AWS and you access them with your AWS user private access key. This key can be store on your AWS account and used on your computer. All of this making them live outside of your repository. But the point is that in order to have those hidden credentials on your CI/CD build machine, you have to somehow give your build machine a way to get to them. Meaning giving it creds that will end up in the repo again.

How are we supposed to do that?

Answer 1

If one has an open source project that is deployed somewhere in the cloud via a continuous delivery pipeline, how can the programmatic credentials needed for the CI/CD to deploy the application remains private?

It really depends on which CI/CD you use.

For instance, I use Travis and Appveyor. Both support to encrypt "secrets" in their manifests.

For instance in this build loop I build Python wheels on Appveyor and they get uploaded to bintray, which would be a minimal Ci/CD-like pipeline of sorts. The same applies here with Travis (for Linux and Mac).

This other loop has the same approach but also uses Docker and things end in bintray too.

If I were to deploy for instance a web app to a live server, I would likely use exactly the same approach. e.g.:

1. if my build is successful and is for a tag ...
2. ... encrypt as secrets the deployment credentials as shown above ...
3. and have my CI handle the decryption and do the actual deployment proper.

But the point is that in order to have those hidden credentials on your CI/CD build machine, you have to somehow give your build machine a way to get to them. Meaning giving it creds that will end up in the repo again.

The thing here is that my regular credentials to the Ci (which are NOT in the repo) are what is used by the Ci tool to encrypt and decrypt at build time my encrypted secrets.

So yes, the Ci knows how to decrypt these credentials. But an attacker would need to have control of the Ci/CD and of their eventually also encrypted auth DB to compromise my "secrets".

If you use a home grown or internally deployed Ci/Cd such as a Jenkins of sorts, you could use the same approach. For instance, use a GPG key or some other mechanism and give the Ci/CD the way to decrypt at runtime. In all cases, at some level you need to trust some of the machines in the pipeline... You could make it more complex by adding intermediaries each with their own credentials too for making it harder.

Answer 2

You manage them as you should manage the credentials for any project, open source or not: by the principle of least access. The development team don't need access to the deployment credentials, so they live in a separate area to which fewer people have access. To take an example: even on the closed source projects I work on, we try very hard not to give any contractors access to anything like deployment keys, just because that means we don't have to worry about re-securing things every time a contractor leaves. You can do exactly the same on an open source project, with only (e.g.) the project owners getting those credentials - most people need access to the artifacts produced by the CI/CD pipeline, not access to reconfigure the pipeline itself.