Roles for our pathogen-repo-build GitHub Actions workflow, take 3 #8
Conversation
tsibley
force-pushed
the
trs/pathogen-repo-build-workflow-3
branch
2 times, most recently
from
4d2114e
to
4dac01b
Compare
Will let us manage (and self-document) our GitHub organization and repo settings via this Terraform configuration.
tsibley
force-pushed
the
trs/pathogen-repo-build-workflow-3
branch
2 times, most recently
from
868c7e9
to
ddc08cf
Compare
|
As none of the changes here should effect production usage—they're all additive or make changes to things not used in production—I've gone ahead and deployed the proposed changes (e.g. run |
A collection of templated repo-specific roles for inside a Nextstrain runtime and one role for the GitHub Actions job itself, i.e. outside the runtime. The inside-the-runtime roles are given pathogen-specific permissions necessary for the ingest and phylogenetic workflows of a pathogen repo. The outside-the-runtime role is only necessary/used at the moment for access to AWS Batch. The roles can only be assumed by specific repos when performed by our centralized pathogen-repo-build workflow. While this doesn't completely prevent off-label use by other GitHub Actions workflows launched from a pathogen repo, it does make it more involved to do so, hopefully to the point of discouragement. The associated GitHub repository configuration is managed by Terraform now as well since the customization of the "sub" claim in GitHub Action's OIDC token is tightly coupled to our AWS role trust policies. Resolves: <#4> Related-to: <nextstrain/private#96>, <nextstrain/.github#81> Supersedes: <#6>, <#7>
tsibley
force-pushed
the
trs/pathogen-repo-build-workflow-3
branch
from
ddc08cf
to
a5883bd
Compare
There was a problem hiding this comment.
Thank you for iterating on this @tsibley 🙏
It's too bad that we are blocked by AWS to fully automate the management of per pathogen repo permissions, but this is definitely better than manually managing roles/credentials per repo.
Separate from this PR, we should have an internal guideline for adding new pathogen repos for automation. Seems like the new docs should live in this repo since this is where we'll have to make changes to opt-in new repos, but also seems hidden in the general infra repo...
| pathogen_repos = tomap({ | ||
| # pathogen name = [repo name, …] | ||
| "dengue" = ["dengue"], | ||
| "forecasts-ncov" = ["forecasts-ncov"], | ||
| "measles" = ["measles"], | ||
| "mpox" = ["mpox"], | ||
| "ncov" = ["ncov", "ncov-ingest"], | ||
| "rsv" = ["rsv"], | ||
| "seasonal-flu" = ["seasonal-flu"], | ||
| "zika" = ["zika"], | ||
| }) |
There was a problem hiding this comment.
So for any future pathogens, we would add them to this map then deploy the terraform changes with terraform apply.
Should we auto-deploy the changes on merge into the main branch?
There was a problem hiding this comment.
Yep, add to that map then terraform apply.
We could definitely auto-deploy… but that does require having very broad admin level access to AWS available in GitHub Actions, which makes me a little nervous. I'd say stick with manual deploys for now.
There was a problem hiding this comment.
When we do want to auto-deploy, the best way to gain that admin-level access would be via OIDC again, scoped down tightly to this repo (and ditto for auto-deploying nextstrain.org's Terraform config).
Yeah. Either AWS or GitHub could make possible what we wanted/needed. AWS by adding more flexible claim → tag mapping. GitHub by adding customized claims.
Indeed. There's several scopes/levels of doc here to consider. I would think to put some brief doc adjacent to |
🎉 YES PLEASE! I would be happy to help out here, whether by beta-testing new instructions or helping to draft them or whatever. I expect I'll be wanting to do this for
Maybe the |
|
Added documentation here for supporting a new repo: 90fec81 |
|
I'm going to merge this. It's already deployed as noted above and won't be used by our repos until we merge nextstrain/.github#81. |
A collection of templated repo-specific roles for inside a Nextstrain runtime and one role for the GitHub Actions job itself, i.e. outside the runtime.
The inside-the-runtime roles are given pathogen-specific permissions necessary for the ingest and phylogenetic workflows of a pathogen repo.
The outside-the-runtime role is only necessary/used at the moment for access to AWS Batch.
The roles can only be assumed by specific repos when performed by our centralized pathogen-repo-build workflow. While this doesn't completely prevent off-label use by other GitHub Actions workflows launched from a pathogen repo, it does make it more involved to do so, hopefully to the point of discouragement. The associated GitHub repository configuration is managed by Terraform now as well since the customization of the "sub" claim in GitHub Action's OIDC token is tightly coupled to our AWS role trust policies.
Resolves: #4
Related-to: https://github.com/nextstrain/private/issues/96, nextstrain/.github#81
Supersedes: #6, #7
Checklist