How do you audit who holds the Google Cloud Run Developer role?

How to audit inheritance of the Google Cloud Run Developer role

Audit it by walking the IAM policy hierarchy from organisation to folder to project and enumerating every principal bound to roles/run.developer. The key question is not just who is listed, but where the binding is inherited from and whether that principal still needs Cloud Run deployment or change rights. In practice, you are auditing effective access, not isolated role entries.

Start with the resource hierarchy because inherited bindings often hide at the parent level. A project may look clean while a folder or organisation policy still grants deployment power to a broad group or service account. For a practical GCP walkthrough of roles, inheritance, service accounts, and least privilege, see Google Cloud IAM and Service Accounts Guide.

Once you have the effective principal list, classify each holder by function. Users, groups, and service accounts should be checked against the actual need to deploy, update, or roll back Cloud Run services, especially where CI/CD systems or shared platform teams are involved. The same review should identify whether the grant is direct, inherited, or attached through a group that has grown beyond its original purpose.

Where the role usually becomes too broad

The most common failure mode is role sprawl through inheritance and convenience grants. Broad developer groups, environment-wide folders, and shared build identities can quietly accumulate permission to change production services even when the original intent was limited to non-production deployment. Google Cloud's broader hierarchy and policy model is explained in Google Cloud Security Guide, which helps you trace where those inherited permissions usually originate.

Cloud Run permissions also tend to expand when teams use platform automation to reduce release friction. If a CI/CD identity can deploy services, it may also be able to change runtime configuration, traffic splitting, or image references, so the role review needs to separate deployment automation from human administrative access. For the serverless-side view of function and service execution access, use Serverless Security Guide.

Another frequent issue is stale ownership. When an application is handed to a new team, moved between environments, or replatformed, old developer grants often remain in place because no one revisits the IAM bindings. That is why the audit has to be tied to ownership changes, not treated as a one-time permissions exercise.

What to verify before you call the review complete

Verify three things: the binding path, the business need, and the blast radius. First, confirm whether each principal gets the role directly or through inherited policy. Second, confirm whether the principal still needs the ability to deploy or modify Cloud Run services. Third, confirm whether the permission scope matches the environment, because a principal with the right in one project may be overexposed if the same access applies across multiple folders or production projects.

Audit the surrounding controls as well. Service account usage, group membership, and change history often reveal whether the binding is still legitimate or just left behind by earlier automation. If the role is granted to a service account used by pipelines, make sure that pipeline identity is still the intended deployment path and not a forgotten backdoor to production.

Risk and Threat Considerations

Overbroad Cloud Run developer access can turn a routine deployment role into a service-level compromise path. If an attacker or careless insider reaches a principal with inherited deployment rights, they may be able to change running services, redirect traffic, or push a malicious image reference without first breaking the whole environment.

Failure mechanism: The risk comes from inherited IAM bindings, shared groups, and long-lived automation identities that outlive their original purpose, so the effective access set is larger than the team believes.

Impact: A stale or overprivileged principal can alter production Cloud Run services, widen the blast radius of a compromise, and make incident scoping harder because the permission came from inheritance rather than an obvious direct grant.

Practitioner Guidance

What to verify: Check the effective IAM policy at each hierarchy level, then compare every role holder against current deployment, release engineering, or platform ownership. If the principal cannot justify service modification rights today, remove the grant or narrow it to the exact environment.

Common mistake: Treating a group name as proof of legitimate access. Group membership, inherited bindings, and pipeline identities change over time, so the audit should validate who can actually act now, not who was supposed to need access when the role was first granted.

Practitioner takeaway: The real control is not merely listing role holders, but proving that every effective holder of roles/run.developer still has a current, bounded reason to change Cloud Run services.

Related resources from NHI Mgmt Group

• How do you audit who holds the Google Cloud Vertex AI Administrator Role?
• How do you audit who holds the Google Cloud Vertex AI User Role?
• How do you audit who holds the Google Cloud Storage Admin role?
• How do you audit who holds the Google Cloud Security Admin Role?