Authenticate the Terraform workflows with OIDC

[ale210]

Part of #182. Deliberately not a closing reference — the last action item on that issue is retiring the static credentials, and that only happens once the runs below are confirmed green. The issue stays open after this merges.

Both Terraform workflows now assume a role through GitHub's OIDC provider instead of passing a long-lived access key and secret.

Workflow	Role	Trust scope	Policy
terraform-plan.yaml	devops-security-tf-plan	refs/heads/* and :pull_request	ReadOnlyAccess
terraform-apply.yaml	devops-security-tf-apply	refs/heads/main only	AdministratorAccess

The branch scoping on the apply role is the security win beyond retiring the keys: a branch or a pull request cannot assume it at all, which is something a static key has no equivalent for.

Both roles already exist. They were created by hand in 035866691871 on 2026-09-05, before this pull request, and are tagged managed-by=exempt. Creating them by hand is deliberate — it dissolves the bootstrap problem where the Terraform that creates the role is run by the workflow that needs the role to authenticate. terraform/aws-gha-oidc-providers.tf now carries a note saying so, because a reader seeing incubator's roles declared and this repo's absent would otherwise "fix" it and reintroduce the circularity.

The plan role is ReadOnlyAccess alone, with no backend policy. The issue predicted it would need dynamodb:PutItem/DeleteItem for state locking. It does not: dflook/terraform-plan adds -lock=false unconditionally, so a plan never touches the lock table. The other three candidates were checked too — the state bucket is AES256 with no customer KMS key, its bucket policy is a TLS-enforcement deny with no principal restriction, and this configuration has no data sources needing more than ReadOnlyAccess. That also explains why incubator-tf-plan has run on ReadOnlyAccess all along; it was never missing a permission.

Why there is a Terraform change in a workflow pull request. Both workflows filter on paths: ['**/*.tf'], so a pull request touching only workflow files triggers neither, and the switch would sit unexercised until somebody else's Terraform change landed. The note in aws-gha-oidc-providers.tf is itself a .tf change, so it makes the plan run here and the apply run on merge. No artificial no-op was needed.

Checked locally before pushing: terraform validate passes on 1.16.0, the version this repo pins. terraform fmt -check reports aws-groups.tf and imports.tf, both of which are untouched by this pull request and already unformatted on main — left alone rather than swept into this change.

Deliberately out of scope:

• Retiring the credentials. Access key AKIAQQWOSJEPUH74UTOJ is still active and both repository secrets are still set. That is the rollback path and it stays until both runs are green.
• aws-actions/configure-aws-credentials stays at v4. Bump configure-aws-credentials to v6 and dflook/terraform-* to v3 in the Terraform workflows #170 bumps it to v6 and rewrites this same step; whichever merges second will need a rebase.

To roll back: revert this pull request. The static key still works, so CI recovers immediately.

[github-actions]

Terraform plan in terraform
With backend config files: terraform/prod.backend.tfvars

No changes. Your infrastructure matches the configuration.

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

✅ Plan applied in Apply Terraform changes on merge #43