IAM Group
Does ZopNight manage IAM Group?
IAM groups let a role be granted once to many identities, which makes the group, not the individual, the right unit for access review. ZopNight records group bindings during discovery, and an optional Google Workspace import resolves member lists and display names for team-level ownership attribution.
Rules that fire on IAM Group
No active rule family targets IAM Group 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 group aggregates users so roles can be granted once to many identities. Group membership determines effective access at scale, making groups the right unit for access review.
Groups as the unit of access review
A group has no price and no meter; its significance is leverage. One binding on a group changes the effective access of every member at once, which is why mature GCP setups grant roles to groups rather than individuals, and why reviewing access binding-by-binding understates reality. The honest question is always two-layered: which groups hold which roles, and who is inside those groups. A perfectly reasonable-looking binding to a team group becomes a finding the moment the group’s membership includes contractors who rolled off last year.
Workspace membership import and when it degrades
ZopDev records group bindings during discovery; optional Google Workspace Groups import enriches team-level ownership attribution. The import resolves each Google Group to its display name and member identities through Cloud Identity, and it degrades precisely rather than loudly: when the discovery credential lacks the Groups Reader role at the organization level (the stub’s Workspace Groups Reader note), lookups return permission denials, partial results still come back, and the gap is reported as a permission issue. It is never conflated with a group that is genuinely empty or contains only service accounts. Teams built from imported groups simply come up empty instead of failing the whole flow.
Group hygiene patterns worth an audit
Three recurring findings. Ghost membership: people who changed teams remain in the old team’s group, quietly accumulating access unions. Nested breadth: a broad role granted to a large all-hands-style group because it was convenient during an incident, never revoked. And orphan groups: bindings pointing at groups whose owning team dissolved, leaving access nobody maintains. Each is invisible at the binding level and obvious the moment memberships are resolved next to roles, which is the view the import exists to produce.
Managing groups from the console
Google Cloud console → IAM & Admin → IAM shows group principals among the project’s bindings; the memberships themselves are managed in Google Workspace admin or Google Groups. Reviewing the 2 surfaces together (bindings in the console, members in Workspace) is what a group-level access review actually means.