How do you audit who holds the Google Cloud Compute Instance Admin (v1) role?

What to look for when auditing Google Cloud instance admin access

The audit starts with the IAM binding itself, not with the individual project page you happen to be looking at. The Compute Instance Admin (v1) role can be granted directly at the organisation, folder, or project level, and inherited access matters just as much as explicit grants. A clean audit answers three questions: who has it, where did they inherit it from, and whether that access is still justified.

Because this role can create, modify, start, stop, and manage Compute Engine instances, the practical audit unit is the principal, not just the role name. That means checking users, groups, service accounts, and any domain-level grants that might widen access beyond the people or workloads you intended to empower. The goal is to separate legitimate operational administration from accidental standing privilege.

In Google Cloud, inherited IAM is often where the surprise lives. A role granted high in the resource hierarchy can silently reach many projects, so the audit should walk from the organisation down through folders into projects and compare effective access at each layer. If you only inspect a single project policy, you can miss broad inherited administration that still applies there.

How to trace effective holders across the hierarchy

Start by enumerating policy bindings for roles/compute.instanceAdmin.v1 across the full hierarchy, then resolve each binding to the effective principals it reaches. That includes direct members as well as nested group membership, since a role may be assigned to a group that contains people who should not all have instance administration.

When the binding is to a service account, confirm whether the service account is still active, what workload or automation uses it, and whether the role is actually required for that use case. A dormant service account with this role is a standing privilege problem, not just an inventory item. NHIMG’s Google Cloud IAM and Service Accounts Guide is the most direct reference for role inheritance, service accounts, keys, and least-privilege review in this environment.

It also helps to distinguish human administration from machine administration. If a non-human principal has instance administration just to support deployment or repair automation, the access should still be justified against a specific operational need, time-bound where possible, and kept as narrow as the workload allows. That is especially important when the same role is granted to a broad group and then inherited by many identities that do not need it.

What a defensible review should conclude

A useful audit does more than produce a list of principals. It should tell you whether each holder needs persistent instance administration, whether the grant is inherited or direct, and whether the access can be reduced to a narrower role or a smaller scope. If a group grant reaches many users, the review should ask who actually needs the permission versus who merely inherited it through convenience.

For broader environment context, Google Cloud’s own hierarchy and audit logging guidance helps verify that your review aligns with the actual resource structure and log coverage you rely on. NHIMG’s Google Cloud Security Guide is useful for understanding hierarchy, organisation policies, audit logs, and cloud security control points that support an access review.

When you need to justify the governance side of the audit, the review should produce evidence suitable for access recertification: who had the role, why they had it, what scope it covered, and what action was taken if the access was excessive. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives supports the audit and recertification mindset that turns an IAM inventory into an accountable control.

Risk and Threat Considerations

Instance admin access is powerful enough that a single overbroad grant can become a fast path to infrastructure tampering, persistence, or data exposure. The main risk is not the role name itself, but the combination of broad inheritance, stale group membership, and dormant service accounts that continue to carry standing privilege after the original need has passed.

Failure mechanism: A project-level or higher-level binding can propagate instance administration far beyond the intended team, while group nesting or forgotten service accounts keep the access alive even after personnel or workload changes.

Impact: An attacker or careless insider who reaches one of those principals can alter compute instances, expand footholds, or use the permission as a stepping stone into adjacent cloud resources.

Practitioner Guidance

What to prioritise: Review inherited grants before you chase direct project bindings. High-level role assignments and broad groups usually create the largest hidden blast radius, so they are the fastest way to reduce exposure.

What to verify: For every principal holding the role, confirm the business justification, whether it is human or service-account based, and whether the access is still needed in production. If the answer is vague, treat it as an exception until it is revalidated.

Practitioner takeaway: The audit is only complete when you can explain every effective holder, every inheritance path, and every standing principal that still has the power to administer compute instances.

Related resources from NHI Mgmt Group

• How do you audit who holds the Google Cloud Storage Admin role?
• How do you audit who holds the Google Cloud Security Admin Role?
• How do you audit who holds the Google Cloud Service Account Key Admin Role?
• How do you audit who holds the Google Cloud Workload Identity Pool Admin Role?