ci: add OIDC-based AWS deploy workflow - #448
Conversation
Adds a workflow_dispatch deploy of a published ghcr release image to the stg or prod ECS stack: verify build provenance, mirror the image into the environment's ECR repository, and roll the service to a new task definition revision. AWS access uses GitHub OIDC role chaining only. Refs #282
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: Comment |
zeljkoX
left a comment
zeljkoX
left a comment
There was a problem hiding this comment.
Looks good.
Few nits:
- The validate job needs
attestations: read. Because the workflow declares explicit permissions, gh attestation verify may otherwise fail when retrieving attestations through the GitHub API. - Both deployment environments must restrict deployment branches to main. A manually dispatched workflow can otherwise run an edited workflow definition from a feature branch and obtain the environment-scoped AWS OIDC identity.
| published GHCR version to the `stg` or `prod` stack without local AWS | ||
| credentials or Terraform state. Run it from the Actions tab with: | ||
|
|
||
| - `environment`: `stg` or `prod` |
There was a problem hiding this comment.
Could we name the GitHub environments after their target networks? devnet, testnet, and eventually mainnet and map each one to the existing AWS resources through environment variables? For example, testnet can keep its stack name, so this does not require renaming the current stack. The infrastructure profile and network remain explicit internal settings rather than being inferred from the environment name.
Address review: GitHub environments are devnet/testnet (mainnet later) and map onto stacks via STACK_NAME; only devnet accepts pre-releases. The validate job needs attestations:read for gh attestation verify under the explicit permissions block. Document that each environment must restrict deployment branches to main.
2 participants
Closes #282.
Adds a
workflow_dispatchworkflow that deploys a publishedghcr.io/openzeppelin/guardianrelease image to the stg or prod ECS stack, using GitHub OIDC role chaining only — no long-lived AWS keys.How it works
environment(stg/prod) andversion(e.g.v1.2.3; prod refuses pre-releases).validatejob resolves the tag to an immutable digest and verifies that digest against the SLSA provenance attestation signed bydocker-publish.yml; prod additionally requires the build to have run fromrefs/tags/<version>, so a manually dispatched build of another branch cannot ship to prod under a release version. This runs before environment protection rules, so prod reviewers only approve an already-verified digest.deployjob (GitHub environmentstg/prod) authenticates via OIDC, checks the ECR repo and ECS service exist, mirrors the verified digest into<stack>-servertagged both<version>andlatest, registers a new revision of the task definition the service is currently running with only the image changed, and waits for stability.latestkeepsscripts/aws-deploy.sh plan/deploy --skip-buildresolving the deployed image, so a later Terraform apply does not roll the service back.Required setup (infra)
stgandprodwith variablesAWS_REGION,ROLE_FOR_OIDC,ROLE_TO_ASSUME,STACK_NAME(guardian/guardian-prod); required reviewers onprodrecommended.repo:OpenZeppelin/guardian:environment:stg|prod.docs/SERVER_AWS_DEPLOY.md.Notes
infra/first, then deploy the image.guardian-evmis out of scope: GHCR release images are built withfeatures=postgresonly.deployment_circuit_breaker { enable = true, rollback = true }on the ECS service so a bad image fails fast instead of timing out the 20-minute wait.docs/SERVER_AWS_DEPLOY.md(new section),infra/README.md(pointer).