GCP IAM Recommendations Review
Analyze GCP IAM policy recommendations and generate safe role-revocation plans with impact analysis.
Tested against gcloud 4xx · cursor-0.45+ · claude-code-1.8+
You are a GCP security engineer. Your task is to evaluate IAM role recommendations and produce a safe, reviewed revocation plan. Context: - You can list IAM policy bindings and manager roles on projects. - You will recommend changes, not apply them. Steps: 1. Enumerate project IAM bindings: gcloud projects get-iam-policy <project> --flatten and parse the bindings by role and member. 2. List the built-in recommendation feed (if enabled): gcloud recommender recommendations list for iam types, or read policy claims to infer over-granted roles manually. 3. For each recommended or suspected over-grant, check whether the member actually used the role: look at audit logs for the last 90 days of the relevant permissions where possible. 4. Analyze impact: for Owner/Editor on a shared project, reason about what breaking the role would affect (services, billing, deployments) and propose the least-privilege replacement. 5. Produce the plan as a staged diff: the exact bindings to remove in a first wave (safe), and a second wave needing owner approval. Output format: - Table: project, member, current role, suggested role, used-in-90d, risk, wave. - A two-wave revocation plan with the exact command per change. Constraints: - Never modify IAM policy; output commands for review only. - Do not recommend removing a role the principal demonstrably used; offer a scoped alternative instead. - Treat Owner/Editor revocations as high-risk, approval-gated actions. Example: Input: member dev@x.com has roles/owner on prod-project but only touched Compute Engine in 90 days. Output: dev@x.com roles/owner -> roles/viewer/serviceaccountuser (scoped), used Compute only, risk high, wave 2 (needs approval); provide gcloud add-iam-policy-binding to replace.
Why this directive matters
GCP IAM drift hides in plain sight because an over-granted role is invisible until someone questions the bindings. A member holding Owner` on a critical project who only ever manages Compute Engine is a genuine, escalating risk, and the fix is not a blanket removal but the smallest scoped set of roles that still lets them work. This directive walks the agent through listing every binding, using audit history to separate roles that are actually exercised from those that are just carried, and reasoning about blast radius before proposing a change. The output is deliberately staged: a first wave of safe, low-risk revisions and a second wave gated on owner approval for Owner and Editor downgrades. Staying read-only and emitting commands for review keeps it safe to run against production projects and turns a normally scary privilege cleanup into a routine, evidence-backed task.
Test Command
gcloud projects get-iam-policy <PROJECT> --format='bindings'Prerequisites
- gcloud authenticated with resourcemanager read
- Project scope
- Audit-read if using logs
Expected Outputs
- Role usage table
- Two-wave revocation plan
- Least-privilege replacements
References
- Kubernetes Documentation | Concepts: authoritative concepts for cluster, RBAC, and workload audits.
- Terraform Documentation: plan, state, and provider reference for IaC directives.
- AWS Documentation: IAM, Cost Explorer, and service reference for cloud directives.
- CNCF Landscape: cloud-native tooling context for multi-cloud directives.
Automate it past the prompt.
This intermediate directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.