IAM Role
Does ZopNight manage IAM Role?
GCP IAM roles are named permission bundles, predefined by Google or custom-built, and cost nothing to grant. Breadth is the risk: Owner and Editor on service accounts are the classic audit finding. ZopNight inventories every role grant during discovery to map who can act on which cost-bearing resources.
Rules that fire on IAM Role
No active rule family targets IAM Role today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
An IAM role is a named collection of permissions granted to identities, either predefined by Google or custom-built. Overly broad roles like Owner and Editor on service accounts are common audit findings.
Predefined bundles, custom bundles, and what a grant really says
A role never appears on an invoice; what it prices is blast radius. Google ships hundreds of predefined roles from narrow viewers to the basic Owner and Editor trio, and organizations add custom roles when no predefined bundle fits. A grant is a compressed statement: this identity may perform these permissions on everything the binding covers. The compression is the problem, because the role’s friendly name is what reviewers read, while the permission list inside is what attackers use. Custom roles drift further, because their contents can change after the grant was approved.
Role grants as ZopNight’s permission map
ZopDev inventories role grants during discovery to map who can act on which cost-bearing resources. The grants are inverted from the project’s IAM policy into per-role rows showing which principals hold each role, and for custom roles the actual permission contents are fetched from the IAM API, so the map reflects what a role contains today rather than what its name implies. As the stub notes, this feeds permission and hygiene analysis, not cost: roles have no meter and no schedule, but they explain who could have created the idle VM the cost side just flagged.
Owner and Editor on service accounts
The classic finding deserves its own heading because of how it happens: a pipeline breaks at 2 AM, someone grants Editor to its service account to unblock the release, and the grant outlives the incident by years. A service account with a basic role is a standing skeleton key. Any workload or person able to act as that account inherits project-wide write access. The audit posture is simple: every basic-role grant to a machine identity should be replaceable with the narrowest predefined role that keeps the pipeline green, and the ones that cannot be explained should be revoked first.
Role administration in the console
Google Cloud console → IAM & Admin → Roles lists predefined and custom roles with their permission contents; the IAM page shows which principals hold them. Reading a suspicious custom role’s permission list there takes 1 minute and regularly ends the debate its name started.