gcp-iamlisted

# Identity and access on Google Cloud Context7 has the full role catalogue and every API signature. What it cannot tell you is **which role to grant**, why the obvious one is usually too broad, and which identity mechanism to use in the first place. That is this document. ## The two rules that prevent most incidents **1. One service account per workload, never the default.** Every project gets default service accounts, and they are granted **Editor** on the project — near-total control. A workload running as the default can read every bucket, write every table, and modify infrastructure. It is the single most common over-privilege in real GCP projects, and it is the default, so it happens by omission rather than decision. Create a dedicated service account per service, grant it only what that service uses, and disable the defaults' automatic grants where the organization policy allows it. When a service needs a new permission, that shows up as an explicit, reviewable grant — which is the entire point. **2. Never create a service-account JSON key.** A downloaded key is a permanent credential with no expiry, and it ends up in a `.env`, a CI variable, a Slack message, a laptop backup. Key leakage is the most common GCP compromise, and it is entirely avoidable — every context that needs an identity has a keyless mechanism: | Context | Use