RFC: scope secretmanager.secrets.setIamPolicy with IAM condition on secret name prefix

[carolinetaymor-qz]

Hi! Sister PR to #42 (N1), same source — another security-audit item from our vendored copy. Opening this one as an RFC because it's a behavior change with downstream-breakage risk, and I wanted to see how y'all felt about it, rather than assuming. We added the change as an opt-in option, so that the default (opt-out) does not change anything.

Context

The runner's project-level custom role currently includes secretmanager.secrets.getIamPolicy and secretmanager.secrets.setIamPolicy, which lets it manage IAM on every secret in the project. The conceptual fix parallels #42: drop the broad permissions, add a smaller role bound with an IAM condition that restricts setIamPolicy to runner-owned secrets only.

Unlike the SA case in #42, secrets don't all belong to the runner in an obvious naming sense. Tightening the default would likely break users whose runner SAs manage IAM on secrets that don't follow a ${runner_name}-* convention. So this PR ships the change as opt-in.

What

This PR adds a new variable, scope_secret_iam_to_runner_prefix (default false, preserving today's behavior). When set to true:

• secretmanager.secrets.getIamPolicy and .setIamPolicy are dropped from the runner's project-level custom role.
• A new custom role runner_secret_iam_manager is created holding only those two permissions.
• The runner SA is granted that role via google_project_iam_member with an IAM condition: resource.name.startsWith(\"projects/<project_id>/secrets/<runner_name>\").

Users who follow the runner-name-prefix convention for their secrets can opt in; users with arbitrary secret names keep current behavior.

Why

Reduces the runner SA's IAM-management blast radius on Secret Manager from project-level to runner-prefixed secrets only. Same risk-reduction rationale as #42.

Open question

This is the part I'd most like your read on:

• Is the opt-in variable shape the right one? I considered just making it the default (parallel to Scope iam.serviceAccounts.setIamPolicy to runner SAs via a separate role #42), but unlike service accounts, secret naming isn't owned by the module — it depends on what the runner creates at runtime. Flipping the default could break deployments with non-prefixed secrets in a way users wouldn't see until the next IAM operation failed at runtime.
• The opt-in variable echoes how use_authoritative_project_metadata is shaped, which seemed like the closest precedent in-tree.
• I'm also happy to drop this entirely if the answer is "the project-level permission is intentional and we don't want a knob."

Happy to iterate on the variable name, the condition expression (e.g., supporting a configurable prefix instead of hardcoding runner_name), or the shape generally.

Testing

• terraform fmt clean
• terraform validate clean
• New bool variable with default false, so terraform-docs will pick it up; no behavior change for existing users on apply

Audit reference

Same audit as #37, #38, #42 — audit item N2.