GitHub Actions: Organization secrets | Hacker News Reader

GitHub Actions: Organization secrets

github.blog

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

[1]: https://github.com/cloudflare/wrangler-action

Nice vid!

> ...a bunch of my projects all deploy w/ actions using the same api token to cloudflare workers...

Assuming some of those are open source, would you please link to them?

This is really cool in a way that will make developers that use Github Actions one day ask, "How did we live without that?"

Yes - this looks like the thing that will get me to start using Github Actions

I was asking for this exact thing on May 1st in slack. Glad it came through, I shelved the project until I could come up with something.

By using a github action I wrote to sync secrets https://github.com/google/secrets-sync-action

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?

You can prevent forks from running actions which guards against external parties.

Nothing to be done about internal parties except policies.

Policies, a verbal rule with your devs?

Mandatory code review would do it.

Not really, because people could change the action on their PR and have it run. Unless you've got a fork based workflow internally.

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.

[1] https://help.github.com/en/actions/hosting-your-own-runners/...

self-hosted runners can be deployed for an org as well https://github.blog/changelog/2020-04-22-github-actions-orga....

Huzzah! That’s great.

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.

I don't get the obsession with secrets...

Why not give us some signed JWTs for external authentication.

Secrets is only good for legacy systems.

Does it come together with the actions feature to Github Enterprise?

f i n a l l y !

This is very welcome, now how about organization-level branch protections please!

Could this replace Vault?

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.

do you happen to have a link to the api docs for that? Everywhere I'm looking it doesn't return the value.

https://developer.github.com/v3/actions/secrets/#get-a-repos...

and the blog states the same behavior I'm seeing in the docs:

  First, the API doesn’t return any values, only names.

https://github.blog/2020-02-06-manage-secrets-and-more-with-...

No, you're right, I was mistaken. Sorry about that.

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.

Reply on news.ycombinator.com