ci.verification_runner_grant — version 1.1

Source: presets/ci/verification-runner-grant.satz

Purpose

Lets a verification runner act as this estate's IaC service account.

One IAM binding: the runner may mint tokens for the estate's service account (roles/iam.serviceAccountTokenCreator), which is the same right a human operator holds through the svc-iac-users group. Nothing else — the runner gets no role on the organisation, because it never acts as itself; satz exchanges its identity for the estate's account before the first API call.

Separate from ci/verification-runner.satz because the two resources belong to two parties in the hosted shape: the runner lives in the MSP's project, this grant lives on the CUSTOMER's account, and the customer applies it.

Estate wiring: nothing to set when the runner pack is used in the same estate — the default names its service account. With the runner elsewhere, set ci_runner_service_account to that runner's email.

Use it

params {
  // the pack's own defaults — copy only the lines you change
  ci_runner_service_account = "satz-runner@{ci_runner_project}.iam.gserviceaccount.com"
}

use "presets/ci/verification-runner-grant.satz"

Needs from outside the pack:

Params

param default
ci_runner_service_account "satz-runner@{ci_runner_project}.iam.gserviceaccount.com"

Questions

What to ask before this pack is configured, and what changing the answer costs.

asks about prompt reversal blast recommends
ci_runner_service_account The runner service account that may become this estate's IaC account edit high —

ci_runner_service_account — This binding is the whole pack: whoever holds this account reads the estate as its service account. The default names the runner pack's own account in the same project; an MSP-hosted runner is named explicitly, and a wrong address either fails every nightly run or hands the estate to an account nobody meant.

Contributes

resource type labels
google_service_account_iam_member verification_runner_impersonates_iac

Claims

None — this pack proves no control by itself.

History

version date change
1.1 2026-09-10 one question block on the runner service account — the binding IS the pack, and a wrong address hands the estate to an account nobody meant. Nothing emitted changes
1.0 2026-09-09 first version: the one binding a verification runner needs — roles/iam.serviceAccountTokenCreator on the estate's IaC service account, and nothing on the organisation. Separate from the runner pack because in the MSP-hosted shape the two resources belong to two parties: the runner in the MSP's project, this grant on the customer's account, applied by the customer. Default names the runner pack's own account, so a customer-hosted estate using both wires nothing

The whole library's history: the changelog in presets/CHANGELOG.md.

Notes

The customer's half of the hosted runner: the runner itself lives in ci.verification_runner, possibly in another organisation's project, and this grant lets its service account become this estate's IaC service account.

Apply it as the customer. Without it the runner authenticates as itself and every live read is refused.