An IAM-admin role that can self-grant owner
Roles that can edit the IAM policy, projectIamAdmin, securityAdmin, organizationAdmin, or mint service-account keys, let the holder grant themselves any other role, so a broad grant is a direct privilege-escalation path.
see_it · fix_it
The misconfig, then the fix
Each verdict below is the actual GCP IAM Least-Privilege Analyzer run on the snippet, not a description of one.
{
"bindings": [
{
"role": "roles/resourcemanager.projectIamAdmin",
"members": ["user:dev@example.com"]
}
]
}Fails · auditor verdictHigh-impact admin role(s) granted: user:dev@example.com on roles/resourcemanager.projectIamAdmin. Roles such as resourcemanager.organizationAdmin, projectIamAdmin and securityAdmin can call setIamPolicy, so the holder can self-grant owner, and serviceAccountKeyAdmin can mint long-lived keys to impersonate any service account. These are direct privilege-escalation paths, not condition nits, so grant the narrowest predefined role for the specific task instead and reserve policy-editing roles for a tiny, reviewed break-glass set.
{
"bindings": [
{
"role": "roles/run.developer",
"members": ["user:dev@example.com"]
}
]
}Passes · auditor verdictNo principal holds an IAM-policy-editing or org-lifecycle admin role from the set checked, so nobody can quietly self-grant owner or mint impersonation keys. Good.
fix · Apply the change shown in the after snippet.
why_it_matters
Some roles are dangerous not for what they do but for what they let the holder become. Any role that can call setIamPolicy (projectIamAdmin, securityAdmin, the folder and org IAM admins, organizationAdmin) can add a binding, including one that grants owner to itself. serviceAccountKeyAdmin can mint long-lived keys for any service account and impersonate it. These aren't least-privilege nits; they're escalation paths that make the rest of your policy moot.
Grant the narrowest predefined role for the specific task instead, and keep policy-editing roles to a tiny, reviewed break-glass set. The analyzer fails any grant of these roles to a non-public principal, because a condition can time-bound such a grant but can't stop the holder from removing the condition once they can edit the policy.
more_misconfigs
Related GCP misconfigurations
faq
Questions & answers
- What is IAM privilege escalation in GCP?
- It's when a principal holds a role that can change the IAM policy itself, such as projectIamAdmin or securityAdmin, and uses it to grant itself a higher role like owner. Any role with setIamPolicy is an escalation path, so it should be reserved for a small break-glass set, not granted for routine work.
- Which GCP roles are privilege-escalation risks?
- The IAM-policy editors (projectIamAdmin, folderIamAdmin, organizationAdmin, securityAdmin, roleAdmin) because they can self-grant any role, and serviceAccountKeyAdmin because it can mint keys to impersonate any service account. The analyzer flags each of these as critical when granted to a non-public principal.
Fixing one binding is easy. Getting the whole project to least privilege is the work.
I review which principals hold primitive and escalation roles, how your workloads are scoped, secrets handling, and the Cloud Run defaults that widen the blast radius. Book a call, or leave your email.
Prefer proof first? See how this plays out in real case studies →