Docs
Open the console →
Guides

Connecting a GCP account

Connect a Google Cloud project to Cloud Control with workload identity federation and Cloud Asset Inventory — read-only, no service-account keys, with health checks.

Connecting Google Cloud is real in Cloud Control. It uses workload identity federation so Cloud Control can impersonate a read-only service account without any exported service-account key.

How the trust works

You configure a workload identity pool that trusts Cloud Control's federated identity and grants it permission to read your project's assets. Cloud Control then uses Cloud Asset Inventory to discover resources read-only. As with AWS, there are no long-lived secrets — you grant a federation you can revoke.

Connect

  1. Start a connection

    On Cloud accounts (/clouds), choose Google Cloud and provide your project id (and project number).

  2. Run the setup script

    Use the provided `gcloud` script to create the workload identity pool, the read-only service account, and the bindings that let Cloud Control impersonate it.

  3. Verify

    Click Verify connection. On success the status becomes healthy and, as with any first healthy connection, the cutover fires and a first sync begins.

Advanced connection parameters

Open Advanced / real connection on the connect form to override the workload-identity pool id, provider id, and the connector service-account email (all default to the cloud-control names shown inline), and to record the regions to discover. These are stored in the connection's encrypted payload and are woven into the generated gcloud script so the commands you run match the connection exactly. A malformed pool/provider id or service-account email is rejected with a 400.

Platform trust settings

The generated gcloud script pins your workload-identity pool to Cloud Control's OIDC issuer, resolved from a stored platform trust setting, then the CC_OIDC_ISSUER environment variable, then a placeholder. Managers see the resolved issuer and its source inline on the connect form; a platform admin sets it from Configure platform trust settings (GET/PUT /api/cloud/settings). With it set, the script shows the real issuer URL, so onboarding is fully driven from the connect UI.

Health, duplicates and disconnect

GCP connections follow the same status vocabulary and the same verification semantics as AWS: exact missing permissions on a 409, transient errors as 503, duplicate connections rejected with the existing id, and non-destructive disconnect. To fully de-provision, remove the workload identity federation config in your project.