My team ~hates~ dislikes the
/test all chatops that I set up in order to run GitHub Actions that require secrets from forks. (I copy/pasted CloudPosse’s
slash-command-dispatch.yaml) We looked at enabling that setting that requires approvals before pipeline runs from forks, but it only requires an approval once from a given user. It’s a mitigation to prevent annoyance and frivolous pipeline runs, not to protect the repo’s secrets.
Is there any other option? I’m sure you guys have looked at this a lot.
For the record, I hate the
/test chat ops as well, the only reason we do it is there is no other way to run the tests for PRs from forks in a safe way
this is why organizations like Kubernetes use chat ops
So it would be helpful to understand what part that needs solving
It’s a mitigation to prevent annoyance and frivolous pipeline runs, not to protect the repo’s secrets.
in this case, require a label to be added to the PR for tests to run
then just have them trigger in standard PR synchronizations
I’ll go look for an example of Kubernetes using chat ops, that would be helpful. Thanks
Jon and I tried a few things.
- We confirmed that secrets are not available to PRs from forks that use the
pull_requestevent, even if they are approved.
- We discovered that the pipeline run approval only happens once for a given user. If I want to do malicious things to this repo I can submit an innocent-looking PR from a fork and have its pipeline run approved, then push a commit that exfiltrates the repo’s secrets. The 2nd pipeline will run automatically without requiring an approval. The mitigation to this is to either ensure pipeline runs do not need secrets to operate or to force a manual review before each pipeline run that needs secrets by doing a chatops command.
We can talk further about it later this afternoon when we meet to discuss the GitLab vs Keycloak thing
can you further define “annoyance and frivolous pipeline runs”?
and, are you able to use filters, instead? split the workflows up, and use filters to declare when they should run…
on: # Run on demand workflow_dispatch: # Run pull requests against the main branch pull_request: branches: [main] paths: - 'Dockerfile.*' - '.github/workflows/build.yml' - 'package-templates/**' # Run when a release is created release: types: [released]
right, but you said it was not about secrets
Right, this setting isn’t about secrets. My needs are about secrets. How can we safely run github actions from forks that need secrets to run, without needing to do the chatops command? My understanding right now is, “you can’t”, but I’m looking for as much information as possible
From people smart on the topic
ahh, it wasn’t clear that the jobs were using secrets, just that chatops was creating kinda “on-demand” runs
i’m not familiar with how slash-command-dispatch works… but even with a pr from a fork, jobs are still triggered even if they use secrets. it’s just the secret is empty. so, presumably, you could have a job that acts like a webhook and kicks off something else that does have access to the secrets?
solution: fire everyone that does not like it, easy
We settled on a hybrid approach, doing as many workflows as we can that don’t require secrets, and still using chatops like we have been for the ones that do need secrets
Thanks for the input everyone! It was super helpful