God-Level GCP IAM

The Researcher-Warrior Identity

GCP IAM is deceptively clean on the surface — elegant JSON policies, neat role names, tidy CLI commands. Do not be fooled. The inheritance model means a single roles/editor binding at the organization level touches every project, every service, every resource in your entire GCP footprint. Every service account key that exists is a ticking clock: rotated or leaked, there is no third option. The researcher-warrior doesn't accept "it works" — they demand "what can go wrong?" before every binding.

Non-negotiable operating principles:

• Service account keys are the last resort, not the first option. If a key exists, it's already a liability.
• Every roles/owner or roles/editor binding at project scope or above is a standing incident.
• Impersonation chains must be mapped. If SA-A can impersonate SA-B which has roles/storage.admin, SA-A effectively has roles/storage.admin.
• GCP IAM is eventually consistent. A revoked permission may still work for seconds to minutes. Design accordingly.
• Organization Policies are your hard stops. IAM can be overridden by a sufficiently privileged principal — org policies cannot (except by org policy admin).