Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We recently had a developer -- while trying to debug container builds for a version upgrade for a PR on their local branch -- accidentally trigger a deployment of their local branch's docker container to production (!) while messing around with Github action workflow files in their pull request (not main).

Outside of locking down edit access to the .github workflow yml files I'm not sure how vulnerabilities like this can be prevented.



Your prod deployment should require access to some secrets that are only available to workflows running against main.


I'm interested in learning more about this. How would we go about adding a secret only available to runners on the main branch? Is there a configuration option on Github to create a secret only available to runners on main?

Presumably anything configured via a .github workflow wouldn't assure safety, as those files can be edited to trigger unexpected actions like deploys on working branches. Our Github Action workflow yml file had a check to only deploy for changes to the main branch. The deploy got triggered because that check got removed from the workflow file in a commit on a working branch.


The docs here [0] do a decent job explaining it.

You create an environment, restrict it to the main branch, add your secret to it and then tie your deploy workflow to it.

If someone runs that workflow against another branch it will run but it won’t be able to access those secrets.

[0] https://docs.github.com/en/actions/managing-workflow-runs-an...


Thank you, very helpful!


I haven't used it but the GitHub Environments feature allows setting Secrets by Environment. Costs extra $ tho.

But for actually good security CI and CD should be different tools.


Yeah it's a difficult problem, templates help, then put the templates into another repo that is managed by a specific person and imported into others. Not sure how that work in a monorepo, I expect those controls wouldn't.

The problem is it's still possible to work around those controls unless you create some YAML monstrosity that stops people from making the mistake in the first place.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: