Skip to content

ci: bind deploy job to the production environment - #1185

Open
jdomeracki-coder wants to merge 1 commit into
mainfrom
glasswing/sec-registry-deploy-environment
Open

jdomeracki-coder wants to merge 1 commit into
mainfrom
glasswing/sec-registry-deploy-environment

Conversation

@jdomeracki-coder

Copy link
Copy Markdown
Contributor

Summary

Part 1 of the fix for coder/security-assessments#350 (SEC: anyone with write access to this repo can assume the project-editor GCP service account).

Adds environment: production to the deploy job in .github/workflows/deploy-registry.yaml. With the job bound to an environment, GitHub mints the OIDC token with:

sub = repo:coder/registry:environment:production

instead of a branch/tag subject. The companion GCP change (coder/gcp PR, part 2) pins the registry-v2-github@coder-registry-1 service account's workloadIdentityUser binding to exactly that subject, replacing the current pool-wide attribute.repository/coder/registry principalSet that matches a token from any branch, PR workflow, or scheduled job in this repo.

The environment's deployment branch/tag policy then becomes the control over which refs may deploy.

Prerequisite (manual, repo settings)

Before merging, create the production environment in this repo (Settings → Environments) with deployment branch/tag policies:

Type Pattern Covers
Branch main push-to-main deploys and the scheduled (cron) run
Tag release/*/*/v* module release tags (release/<ns>/<name>/vX.Y.Z) — GitHub's * does not match /, so this matches exactly the 3-segment release tags

Optionally add required reviewers to the environment for human-in-the-loop production deploys (also mitigates #353).

If the environment does not exist when this merges, GitHub auto-creates an unprotected production environment on first run — deploys keep working, but the ref policy is not enforced until configured, so please create/configure it first.

Rollout order

  1. Create + configure the production environment (above).
  2. Merge this PR — safe to merge first: the current GCP binding is a repository-wide principalSet, which also matches the new environment subject.
  3. Merge the companion coder/gcp PR (pins the GCP binding to the environment subject and drops roles/editor).

Order matters only for step 3: merging the GCP change before this one would lock the deploy workflow out (fail-closed, no security impact).

Notes

  • No change to triggers, permissions, or deploy steps; id-token: write is unchanged.
  • .github/ is owned by @jdomeracki-coder per CODEOWNERS.

Filed as part of the Glasswing security assessment (coder/security-assessments#347).

Pins the deploy job's GitHub OIDC subject to
repo:coder/registry:environment:production so the GCP side
(coder/gcp projects/production/coder-registry-1) can trust that single
subject instead of a pool-wide repository principalSet that matched any
branch, PR, or workflow of this repo.

The 'production' environment's deployment branch/tag policy
(main + release/*/*/v* tags) then controls which refs may deploy.

Part of the fix for coder/security-assessments#350.

Requires: the 'production' environment must exist in repo settings with
deployment branch/tag policies 'main' (branch) and 'release/*/*/v*' (tag)
before the GCP-side binding change merges; this change itself is safe to
merge first (the current principalSet binding matches any subject from
this repo, including the environment subject).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant