Create new role for GH Action access to S3

[joverlee521]

Context

See https://github.com/nextstrain/private/issues/96#issuecomment-2078009430

Description

1. import existing IAM policies defining access to our AWS S3 buckets
   • AllowEditingOfNextstrainDataBucket
   • AllowEditingOfNextstrainDataPrivateBucket
   • AllowEditingOfNextstrainNcovPrivateBucket
   • AllowEditingOfNextstrainStagingBucket
2. Create new role for GH Action access to S3 (GitHubActionsRoleNextstrainS3Access?)
   • with managed_policy_arns pointing to imported policies.
   • with "token.actions.githubusercontent.com:sub": "repo:nextstrain/* to allow all Nextstrain repos to assume the role.

[joverlee521]

Just found prior art for using AWS IAM role + inline session policy for per-repo accession privileges: https://github.com/Skyscanner/gha-aws-oidc-sample

Important note on requiring reusable workflows, along with the note in the GH Action OIDC docs:

Note: When the organization template is applied, it will not affect any workflows in existing repositories that already use OIDC. For existing repositories, as well as any new repositories that are created after the template has been applied, the repository owner will need to use the REST API to opt in to receive this configuration. Alternatively, the repository owner could use the REST API to apply a different configuration specific to the repository. For more information, see "REST API endpoints for GitHub Actions OIDC."

[joverlee521]

So we would limit the the role to usage of the pathogen-repo-build workflow:

"token.actions.githubusercontent.com:sub": "repo:nextstrain/*:job_workflow_ref:nextstrain/.github/.github/workflows/pathogen-repo-build.yaml@*"

Set the customization template for an OIDC subject claim for an organization

curl -L \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/orgs/nextstrain/actions/oidc/customization/sub \
  -d '{"include_claim_keys":["repo", "job_workflow_ref"]}'

Then whenever a new pathogen repo wants to use the pathogen-repo-build workflow, opt in to the org's custom claims

curl -L \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://api.github.com/repos/nextstrain/<pathogen-repo>/actions/oidc/customization/sub \
  -d '{"use_default":false}'

[joverlee521]

I don't see why individual repo's shouldn't just automatically opt-in to the org's custom claims.
We could set up a GH Action to just opt-in all nextstrain org repos.

[tsibley]

@joverlee521 Ah, yes, I'd also come to the conclusion to modify the subject claim after we last talked… but didn't communicate it. Sorry! orz but I kinda thought we'd said I was on the hook for the IAM bits and you'd do the GH workflow bits.

1. import existing IAM policies defining access to our AWS S3 buckets

   • AllowEditingOfNextstrainDataBucket
   • AllowEditingOfNextstrainDataPrivateBucket
   • AllowEditingOfNextstrainNcovPrivateBucket
   • AllowEditingOfNextstrainStagingBucket

I'm not sure, will need to check on them, but we'll want to make sure these are appropriately limited for automation (e.g. no ability to delete object versions, etc.). They were created with individuals in mind, I think.

[joverlee521]

I kinda thought we'd said I was on the hook for the IAM bits and you'd do the GH workflow bits.

Yup! This was just my brain dump before I started setting up the role/session interaction within the GH workflow.

[joverlee521]

I have a draft PR for supporting the runtime AWS role/session within pathogen-repo-build. We can coordinate testing once the new role is created.