roles/owner handed out day to day
roles/owner is a primitive role with full control over every resource plus the ability to rewrite IAM, so granting it for day-to-day work bypasses least privilege entirely.
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/owner",
"members": ["user:dev@example.com"]
}
]
}Fails · auditor verdictroles/owner granted to: user:dev@example.com. Owner is a primitive role with full control over every resource plus the ability to change IAM, so it bypasses least privilege entirely. Keep owner to a tiny set of break-glass humans and replace day-to-day grants with predefined roles scoped to the job.
{
"bindings": [
{
"role": "roles/run.developer",
"members": ["user:dev@example.com"]
}
]
}Passes · auditor verdictNo principal holds roles/owner, so nobody has blanket control plus IAM-admin from a single grant. Good.
fix · Apply the change shown in the after snippet.
why_it_matters
Owner is the most powerful primitive role: it can read, write, and delete every resource in the project, and it can change IAM, which means an owner can grant themselves or anyone else any other role. Handing it to a developer or a service account "so things just work" collapses your whole access model into one grant. If that account is phished or its key leaks, the attacker owns the project.
Keep owner for a tiny, named break-glass set of humans, reviewed regularly, and replace day-to-day grants with predefined roles scoped to the job: run.developer, storage.objectAdmin, cloudsql.client, and so on. The analyzer fails any owner grant to a user, group, or service account, because owner is never the right answer for routine access.
more_misconfigs
Related GCP misconfigurations
faq
Questions & answers
- Is it bad to grant roles/owner in GCP?
- For anything routine, yes. Owner has full control of every resource and can rewrite IAM, so it bypasses least privilege and makes one compromised account a project takeover. Reserve owner for a small break-glass set and use scoped predefined roles for day-to-day access.
- What should I use instead of roles/owner or roles/editor?
- Predefined roles scoped to the services a principal actually uses: roles/run.developer for deploying services, roles/storage.objectAdmin for a bucket, roles/cloudsql.client for database access. They cover the real job without the blanket write access and IAM control that the primitive roles carry.
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 →