-
Notifications
You must be signed in to change notification settings - Fork 4
Open
Description
Mentioned in #196, we have a configured GitHub secret that is used to sign keys. Such secrets are made available to GitHub workflow jobs triggered by pushes to the repo, independent of branch etc. They can be constrained to be available only in workflow jobs with specific "environment" configured.
Here is a quick list of things I think can be done:
- (already done) Adjust workflow triggers
If you develop in a branch that you push to, and open a PR, you trigger the workflow twice I think. Once for pushing to the branch, and once for having a PR be updated. The push triggered workflow has secret access, while the pull request triggered workflow doesn't I think. (EDIT: a pull_request triggered job will or will not see secrets depending on if it originates from a branch in the repo, so this won't help) - Work in forks
By using forks, we our development branches lives outside this repo, and won't ever get access to the main repo's secrets until the pull request merge leads to a push to main. - Environment scoping
Make the secret scoped to specific environments, such as a "java release" environment, and let only the jobs that may consume it declared to use that environment. - (already done) reference secrets to set environment variables only on specific steps that needs it
I believe there are ways a step can access a secret without reading environment variables, but we avoid making it trivial to read it by doing this at least.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels