I have an open source project on GitHub and I want to commit to the “gh-pages” branch from the container. To do so I need (according to the CircleCI manual) to create a r-w deploy key and add the “add_ssh_keys” step. Same time the manual has a note that any code running in the container could read/steal those keys. Does this mean that forked pull requests could steal them? What other options do I have? I think it’s pretty common workflow these days.
- 1 we have the same issue. It actually seems like deploy keys, user keys or even environment variables have the same vulnerability here.
As an open source project anyone could just modify our circlcie/config.yaml and print out any info they want and boom, they can do anything on our repo. How should open source projects address this?
Can you detail your needs/expectations in more detail as the original post is a little dated?
You are correct, the placing of ssh key (or any value) into the config.yaml would result in those values being visible to everyone. The key question is why would you create an environment where an open-source project wants/needs access to a private repo?
The CircleCI project settings also provide certain features to get around this type of issue as values (variables and keys) can be stored at the project our organization level, rather than within the config.yaml files. As these are injected at the time the workflow is executed they are never visible to anyone who views or forks the repo.
mozilla/addons-server is the project in github.
We have a deploy key with read only access. Our use case is.
In CI we have a job that should generate some code, commit, push to a branch and open a PR.
To do this, we need to push to our public github repository.
If we just made our deploy key have write access then anyone who forks our project could just get the key and start pushing to whatever branch they want.
There seem to be sufficient protections in place to prevent external contributors from accessing this info via ssh as they can neither create nor access “re-run with ssh” jobs.
But, they could just cat the private key by modifying our config.yaml or they could modify the config to just push whatever they want to master or any other branch.
Is there a way for the deploy key to be masked in the same way that environment variables are? And is there way to prevent forks from having write access or to use a different deploy key that only has read access?
The only alternative we see currently is to use a PAT but this introduces a whole different set of problems as we have to use a bot account which might not work in terms of authentication on github side and is additional overhead. Using an actual user PAT is also probably not a good idea.
Thoughts?
There are a few things I can comment on, but my answer is not going to be 100% of the solution you are looking for as my focus is on private repos as I use CircleCI within a business environment.
“But, they could just cat the private key by modifying our config.yaml or they could modify the config to just push whatever they want to master or any other branch.”
You should not be allowing your wider community the ability to cause a build from within your github/CircleCI environment. As you say the loss of info from within the build process is a risk, but so is someone changing your repo to do some crypto mining or denial of service attack. The reputation risk to your project is high as is the likelihood that your CircleCI account will get blocked for misuse.
“Is there a way for the deploy key to be masked in the same way that environment variables are? And is there way to prevent forks from having write access or to use a different deploy key that only has read access?”
The ‘masking’ is no more than basic output obscuring, if someone can modify the config.yaml file and view the results they can access all data that the job environment has access to. This in turn means that any values placed in the user account ssh files can be accessed.
As for a final solution, this is where I can say that I’m not in any real position to say what should be done as I don’t have the right background to propose a valid solution. Is there not some form of project forum within the Mozilla ecosystem as other projects must have had to deal with this separation of public repo/operational process before?
I have made this a separate reply as it is just an indication of how I would try and resolve the issue myself (taking into account all the caveats I have listed about my knowledge).
- I would move the build process to an independent project, which has far more restrictive access rights.
- All the keys used within the circleci.yaml file would then be moved to within the CircleCI project setting. This would allow them to be referenced as environment variables within the circleci.yaml, but their values remain hidden from view.
To link the 2 projects together I would do something rather simple and messy with a cron job, but your wider community should be able to help you use GitHub webhooks to trigger the build when the main project is changed. My own environment is BitBucket based so I do not have any experience with this.