Google Cloud

Overview

The Clarity Google Cloud connector is read-only. It never writes to Google Cloud. It reads who holds which IAM role, and where, across your whole organization.

Conditional bindings are kept:

• A binding limited to a time window shows [until YYYY-MM-DD] while it is open.

• Once the window has passed it shows [expired YYYY-MM-DD]. An expired binding is kept and lists who held it, but it is not counted as current access and never appears as live access in a review.

• A window that has not started yet shows [not active until YYYY-MM-DD]. It is kept as pending: not current access, and not expired.

• Any other condition shows [conditional: <title>], and the rule is kept exactly as written.

The basic roles Owner, Editor and Viewer are tagged high risk by Clarity’s Google Cloud tag rules.

Prerequisites

You need:

• A Google Cloud administrator who can create a service account and key in one project, and grant IAM roles at the organization level (for example, an Organization Administrator).

• A Google Workspace / Cloud Identity super administrator, to assign the Groups Reader admin role in the Google Admin console.

• Your numeric Google Cloud organization ID.

Note: Many Google Cloud organizations block service account key creation through the organization policy Disable service account key creation. If Google refuses to create the key in Step 1, an Organization Policy Administrator must allow key creation for the project that hosts the Clarity service account.

Step 1 — Create a read-only service account

In the Google Cloud console, choose a project to host the connector’s service account (any project in the organization).

1. IAM & Admin → Service Accounts → Create service account. Name it, for example, clarity-reader. Grant it no roles on this screen.

2. Open the new account → Keys → Add key → Create new key → JSON. A JSON key file downloads. Treat it like a password: it is the only credential Clarity needs.

3. Make sure these APIs are enabled on that host project (APIs & Services → Library):

   • Cloud Asset API

   • Cloud Resource Manager API

   • Identity and Access Management (IAM) API

   • Cloud Identity API

Step 2 — Grant the service account read roles on the organization

At the organization node (IAM & Admin → IAM, with the organization selected), grant the service account:

None of these roles can change anything.

Step 3 — Let the service account read Google groups

In the Google Admin console (admin.google.com): Account → Admin roles → Groups Reader → Assign service accounts, and add the service account’s email address.

Without Groups Reader, no group can be read and the sync fails with:

Cloud Identity groups unreadable: check the service account’s Groups Reader role

A single group Clarity cannot read (for example, one owned by another organization) still appears as an entitlement, but its members are not read.

Step 4 — Enter the credentials in Clarity

Applications → Add application → Google Cloud.

Click Next. This will automatically trigger a test that reads the organization and one page of IAM policies. A failure here usually means the organization ID is wrong, or the Browser or Cloud Asset Viewer role is missing at the organization.

What to expect

• Names follow renames and moves. Each entitlement is keyed to the role plus the node’s numeric ID. When a folder is renamed or a project moves, the entitlement’s name changes, but its tags, review history and requests stay with it.

• Changing a condition creates a new entitlement. Google treats a binding with a different condition as a different binding, so a changed condition appears as a new entitlement, and the old one is retired.

• Holders that are not people (allUsers, allAuthenticatedUsers, domain:, identity pools, whole-customer group members) appear as accounts named, for example, Anyone on the internet or Domain example.com. They are never matched to a person, so they show up as unreconciled accounts in reviews. That is how a public or domain-wide grant reaches a reviewer.

• One locked-down project stops the sync. If the service account cannot list the service accounts of a project (for example, inside a VPC Service Controls perimeter), the sync fails rather than treating that project’s accounts as removed. Grant Service Account Viewer there, or add the connector’s project to the perimeter.

What Clarity does NOT do

• No changes in Google Cloud. Clarity never adds, removes or changes a binding, a group or a service account.

• Not synced in this version: individual resources (buckets, VMs and so on) and the organization tree as its own objects, deny policies, GKE / Kubernetes RBAC, the permissions inside Google’s predefined roles, Organization Policy, and VPC Service Controls.

Need Help?