Repository navigation
fix(iam): pin javabin-ci-infra to platform-ci.yml on main - #161
Conversation
Terraform Plan🚧 Changes detected — Plan: 0 to add, 1 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟡 MEDIUM Plan updates one IAM role (javabin-ci-infra) in place by adding a job_workflow_ref condition to its GitHub OIDC trust policy; no creates or destroys.
|
Terraform Plan🚧 Changes detected — Plan: 0 to add, 1 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟡 MEDIUM Plan updates one IAM role (javabin-ci-infra) in place by adding a StringLike trust-policy condition restricting GitHub OIDC job_workflow_ref to javaBin/platform's platform-ci.yml on main; no creates or destroys.
|
|
Review fix: corrected the role table in docs/platform-modules.md. javabin-ci-infra-plan trusts any platform branch / PR, and the app rows now describe the broker model (ci-app-broker, ci-team-{team}, ci-deploy-{team}). |
The production-environment OIDC sub carries no branch, so any branch that declared the environment could assume the apply role. Require job_workflow_ref = platform-ci.yml@refs/heads/main, and move the drift job to the read-only plan role so apply is the only ci-infra user. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
c4abf1b to
db4cb43
Compare
Terraform Plan🚧 Changes detected — Plan: 0 to add, 1 to change, 0 to destroy. Plan outputLLM ReviewRisk: 🟡 MEDIUM Plan updates one IAM role (javabin-ci-infra) in place by adding a job_workflow_ref condition to its GitHub OIDC trust policy; no creates or destroys.
|
Why
javabin-ci-infra(AllowAll inside the org boundary) trusts the OIDC subrepo:javaBin/platform:environment:production. That sub has no branch in it. Theproductionenvironment currently has no branch policy and no protection rules (gh api repos/javaBin/platform/environments). So a workflow pushed to any branch that declaresenvironment: productioncan assume the apply role. The org default repo permission iswrite, which makes that 38 people. This is finding C1 in the security audit.What
iam/main.tf: theci_infratrust now also requirestoken.actions.githubusercontent.com:job_workflow_ref = javaBin/platform/.github/workflows/platform-ci.yml@refs/heads/main. Both existingsubvalues stay. Onlyplatform-ci.ymlas committed on main can assume the role now, whatever the environment settings say.platform-ci.yml: the weeklydriftjob usesjavabin-ci-infra-planinstead ofjavabin-ci-infra. Drift only plans. The plan role already has ReadOnlyAccess, the infra lock table, andssm:GetParameteron/javabin/slack/*for the webhook. After this change the apply job is the only user ofjavabin-ci-infra.ci-workflow.mdandplatform-modules.mddescribe the new trust.This is defence in depth. The GitHub-side fix is to limit
productiontomain. That is a manual settings change, listed in the audit report.How verified
terraform fmt -recursive -checkandterraform validate(aws provider 5.100.0) pass.python -m pytest terraform/lambda-src/tests scripts/testspasses (107 tests).job_workflow_refcondition key already works in this account.javabin-ci-app-broker,javabin-ci-apply-gateandjavabin-ci-override-approveruse it, and all three were used today.push,workflow_dispatchandrepository_dispatch, all gated torefs/heads/main. Each of these producesjob_workflow_ref = ...platform-ci.yml@refs/heads/main.module.iam.aws_iam_role.ci_infra(trust policy only).Rollback
The apply that changes the trust runs with credentials it assumed before the change. If a later apply is rejected, an admin SSO session can revert this one resource locally with
terraform apply. The other option is to remove thejob_workflow_refcondition from the role trust in the IAM console.Follow-ups
productionenvironment tomain. The commands are in the audit report.🤖 Generated with Claude Code