Scope iam.serviceAccounts.setIamPolicy to runner SAs via a separate role

[carolinetaymor-qz]

Hi! Continuing the run of mostly security-focused patches from our vendored copy of this module — same context as #37 and #38.

The runner's project-level custom role currently includes iam.serviceAccounts.getIamPolicy and iam.serviceAccounts.setIamPolicy, which lets the runner manage IAM on every service account in the project. The module already uses per-SA bindings for roles/iam.serviceAccountUser (only on the runner, environment_vm, and proxy_vm SAs); this PR extends the same scoping to the getIamPolicy/setIamPolicy permissions.

What changes:

• Drop iam.serviceAccounts.getIamPolicy and iam.serviceAccounts.setIamPolicy from the runner's project-level custom role.
• Add a new small custom role runner_sa_iam_manager holding only those two permissions.
• Bind the new role at the SA level (via google_service_account_iam_member) on the runner, environment_vm, and proxy_vm SAs — not at the project level.

Effect: the runner can still manage IAM policies on the three SAs it actually attaches to instances and instance templates, but can no longer touch IAM on unrelated service accounts in the project.

Migration note

Existing deployments will see a one-time delta on next apply: the two permissions drop from the existing runner custom role, the new *_sa_iam_mgr custom role is created, and three google_service_account_iam_member resources are created. No state moves needed; the resource graph just expands.

Testing

• terraform fmt clean
• terraform validate clean
• No variable or output changes, so terraform-docs regen isn't needed
• We've been running this in our fork for a while with no problems

Audit reference

This came out of the same security audit on our vendored copy — audit item N1.