this is a really awesome improvement - a bunch of my projects all deploy w/ actions using the same api token to cloudflare workers (using wrangler-action[1]), so this makes it super easy to add new projects or re-roll the key without having to go in and change each project's config.
btw, if you're looking for an intro to github actions, i put out a video last december covering publishing your first github action workflow: https://youtu.be/J4EhgEskSZA
Cant you create a github action in a commit that simply spits the secret out? Anyone know how to prevent this hack? Is there a way to have an open repo except for the actions folder?
Great to see. I've definitely missed it coming from circleci where you have contexts where you can define secrets that you can share across multiple repos
Awesome. Now we just need the ability for self hosted runners[1] to support multiple repos. As I understand it, currently you need to deploy a dedicated runner per repo.
I wish GitHub Actions had a mechanism for authenticating to third-party services without secrets.
It could be as simple as calling a metadata API only available from inside a GitHub Actions container and obtain a oauth2 token/JWT for an external audience.
This would be great. Then we could reliably use something like vault to store secrets with individual acls per-workflow, and have reasonable confidence that only that single workflow can access them.
If your only use case for Vault is access to K/V secrets during a workflow (CD for example) -- then sure, it's a much simpler alternative. If you need access to secrets dynamically / at runtime (outside of the Actions container), or any of the other features Vault has, then no.
I’m not sure if you’re aware but the GitHub API provides dynamic access to the secrets so you can theoretically use it in your application/outside your workflow.
Not really. Vault offering is very extensive. Their product doesn't make much sense if all you were looking for was a simple deployment of your average amateur or small SaaS. Org and repositories secrets are simple security solutions for people who can't afford to use Vault.
It makes using org-level AppRoles with Vault really easy, but I wouldn't replace Vault with this. I use org contexts with CircleCI today to do this with a very generic AppRole that has access too 'secrets that should be in Vault, but are generally safe.' e.g.: a consul credential that can read/write from the terraform state area.
btw, if you're looking for an intro to github actions, i put out a video last december covering publishing your first github action workflow: https://youtu.be/J4EhgEskSZA
[1]: https://github.com/cloudflare/wrangler-action