9

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?

  • 1
    This question has zilch to do with Open Source. The exact same issue could arise with closed-source proprietary software. This question is a better fit for SO or Superuser. – DepressedDaniel Feb 25 '17 at 3:54
  • 2
    @DepressedDaniel Umm... What? It's an issue you'd face when running an open source project - an issue that you'd most definitely face when hosting a repository and using a tool such as Travis CI to run tests. I think it works fine here. – Zizouz212 Feb 26 '17 at 20:19
  • @Zizouz212 It's an issue you'd face with OSS but it is not exclusive to OSS. "I got a kidney stones attack while I was in a wheelchair" belongs in a kidney stones forum, not a wheelchair forum. – DepressedDaniel Feb 26 '17 at 20:46
  • 3
    It's all fun and games to ping-pong from a SE to another and having arguments on why it's not exclusive but since it's applicable to OSS... How do OSS do it..? Trying to solve the darn question would be more productive than this. Also, I'm still looking for an actual concrete answer since I'm scratching my head with this one for too long now. I'm starting a bounty. – Xavier Huppé Mar 1 '17 at 18:53
6
+50

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.

5

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.

  • 3
    I think you misunderstood my question. I'm not talking about managing how much people has the creds to the CI/CD service. I'm asking about how we give the CI/CD the ability to deploy by itself. This requires creds that needs to be in a configuration file the CI/CD will use during the pipeline execution. This file has to be in the repository to be picked up but in an open source project it's an issue since everyone could grap those from github and push cat photos to my website. – Xavier Huppé Feb 23 '17 at 19:29
  • 3
    No, I've understood the question, you're making a bad assumption: "This file has to be in the repository to be picked up" - no, it doesn't. You have it in a separate store (repo, if you want, but that's solutionizing) that is accessible by the CI/CD infrastructure, but not by the whole world. – Philip Kendall Feb 23 '17 at 19:37
  • 4
    I typically use environment variables for this. Particularly useful if you have multiple target environments (test vs prod) – RubberDuck Feb 23 '17 at 22:10
  • @Sinity: I love cat photos. More seriously some feedback on my answer would be welcomed. – Philippe Ombredanne Mar 3 '17 at 13:16
  • @RubberDuck How do you secure your variables against a developer dumping all your env. Variables to a file? Same for your solution PhilipKendall: How to prevent code in your repo that reads you file during build? – gorootde Sep 15 '17 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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