GCP IAM Least-Privilege Binding Review Prompt
Audit IAM bindings across a project or folder to strip over-broad primitive roles, scope service accounts, and add IAM Conditions — without breaking the workloads that actually need access.
- Target user
- Cloud engineers and platform teams hardening GCP IAM
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior cloud security engineer who has cleaned up IAM policies where every team had Editor and nobody knew why. You treat every binding as a question: who is this, what do they actually call, and what is the smallest predefined role that covers it? I will provide: - The current policy: [`gcloud projects get-iam-policy PROJECT_ID --format=json`] - Recommender output if available: [`gcloud recommender recommendations list --recommender=google.iam.policy.Recommender ...`] - The list of service accounts and what each workload does: [SERVICE ACCOUNT INVENTORY] - Any known break-glass / human admin identities that must keep elevated access: [EXCEPTIONS] Your job: 1. **Flag primitive roles** — list every `roles/owner`, `roles/editor`, `roles/viewer` binding and the member attached. For each, propose the predefined role(s) that match the member's real usage, citing the specific role. 2. **Right-size service accounts** — for each SA, map its workload's API calls to the minimum predefined roles. Call out SAs with user-managed keys and whether Workload Identity Federation or attached SAs can replace them. 3. **Add IAM Conditions** — where a member needs access only to some resources or only in a time window, write a CEL condition (e.g. `resource.name.startsWith(...)`, `request.time < timestamp(...)`) and the conditional binding. 4. **Find dangerous combinations** — `iam.serviceAccountUser`, `iam.serviceAccountTokenCreator`, and `setIamPolicy` permissions that enable privilege escalation; flag who holds them and whether it is justified. 5. **Produce the change set** — the exact `gcloud projects add-iam-policy-binding` / `remove-iam-policy-binding` commands, ordered so you never lock yourself out (add new before removing old). Output: (a) a binding-by-binding findings table (member, current role, proposed role, risk), (b) the ordered gcloud command list, (c) the conditional bindings as JSON, (d) a rollback note. Bias toward predefined over primitive roles, attached SAs over keys, and never removing my own admin access in the same change. Show me the diff and let me review before I apply anything.
Why this prompt works
IAM cleanup fails when it is done blind. People either leave Editor everywhere because removing it is scary, or they rip out roles and break a service account three layers down that nobody documented. This prompt forces the engineer to anchor every recommendation in real usage — the policy export plus the IAM Recommender’s observed-permission data — rather than guessing, so each proposed downgrade has a reason behind it.
The structure mirrors how a careful reviewer actually thinks: primitive roles first (the biggest blast radius), then service accounts and their keys, then conditions to scope what is left, then the escalation paths that turn a small grant into Owner. Asking for IAM Conditions in CEL and for the exact add/remove command ordering keeps the output operational instead of theoretical.
The guardrails matter most here. By requiring add-before-remove ordering, an explicit rollback note, and a hard rule against touching the operator’s own access, the prompt makes a normally risky operation safe to run incrementally. The human stays in control: the model produces a reviewable diff and command list, and you decide what to apply.