Summary
Track operator review of Compute Admin grants created by older configure-gcp versions. PR #2122 prevents new broad grants but deliberately preserves existing IAM policies.
Current behaviour
Before #2122, Step 4 granted roles/compute.admin to the CUDly service account. The merged wizard now grants Compute Viewer plus an exact commitment-purchase role, but rerunning it does not revoke old broad grants. No live project inventory was performed, so the presence or number of affected installations is unknown.
Steps to verify the gap
With the project owner's authorization, inventory CUDly service accounts and their direct and inherited role bindings. Identify identities created by the old wizard that still have Compute Admin access. Do not change live IAM as part of the inventory.
Expected behaviour
Existing installations have an explicit, owner-approved path to the narrower runtime grants. Unrelated access and IAM conditions remain intact.
Proposed fix
- Extend
docs/cli/cloud-setup.md:150 with a migration checklist: identify broad grants, establish narrow permissions, verify the actual CUD workflow without purchasing, and obtain approval for any revocation.
- Record the inventory result and any deployment-specific follow-up. Do not automatically delete bindings or rotate keys without per-resource authorization.
- Include authorized live IAM validation of the replacement role; local HTTP fixtures only prove SDK request behaviour.
References
Severity
High if a legacy grant remains: that identity retains Compute infrastructure administration. No affected live installation has been confirmed. This issue tracks the inventory and owner-controlled remediation, not an authorized cloud mutation.
Summary
Track operator review of Compute Admin grants created by older
configure-gcpversions. PR #2122 prevents new broad grants but deliberately preserves existing IAM policies.Current behaviour
Before #2122, Step 4 granted
roles/compute.adminto the CUDly service account. The merged wizard now grants Compute Viewer plus an exact commitment-purchase role, but rerunning it does not revoke old broad grants. No live project inventory was performed, so the presence or number of affected installations is unknown.Steps to verify the gap
With the project owner's authorization, inventory CUDly service accounts and their direct and inherited role bindings. Identify identities created by the old wizard that still have Compute Admin access. Do not change live IAM as part of the inventory.
Expected behaviour
Existing installations have an explicit, owner-approved path to the narrower runtime grants. Unrelated access and IAM conditions remain intact.
Proposed fix
docs/cli/cloud-setup.md:150with a migration checklist: identify broad grants, establish narrow permissions, verify the actual CUD workflow without purchasing, and obtain approval for any revocation.References
76d1d4e72f13731ba071c7932f8e7e233cb4f6c6cmd/configure_gcp.go:gcpStepGrantRoleSeverity
High if a legacy grant remains: that identity retains Compute infrastructure administration. No affected live installation has been confirmed. This issue tracks the inventory and owner-controlled remediation, not an authorized cloud mutation.