Google Cloud setup

• cloudasset.googleapis.com — all Asset-API endpoints (compute, storage, IAM bindings, …); the bulk of the 27
• cloudresourcemanager.googleapis.com — Projects, Organizations, Folders
• cloudbilling.googleapis.com — Billing Accounts
• iam.googleapis.com — Service Accounts, Service Account Keys
• serviceusage.googleapis.com — APIs Enabled (per Project); usually already on
• logging.googleapis.com — Audit Logs (Admin Activity)
• bigquery.googleapis.com — billing cost + pricing (queries the BigQuery export)
• billingbudgets.googleapis.com — Billing Budgets
• admin.googleapis.com — only for Cloud Identity Users (optional, Step 6)

gcloud services enable cloudasset.googleapis.com cloudresourcemanager.googleapis.com \
  cloudbilling.googleapis.com iam.googleapis.com serviceusage.googleapis.com \
  logging.googleapis.com bigquery.googleapis.com billingbudgets.googleapis.com \
  --project=YOUR_SA_HOST_PROJECT

Propagation. After enabling, SERVICE_DISABLED 403s can persist intermittently for ~10–15 minutes — some calls succeed while others still fail as the change rolls out across Google’s systems. Wait it out before assuming a misconfiguration.

​

Step 1: Identify your IDs

1. GCP_ORG_ID — Open https://console.cloud.google.com/iam-admin/settings, switch to your organization in the picker, copy the Organization ID (e.g. 123456789012).
2. GCP_CUSTOMER_ID — In the same Organization Settings page, copy the Directory customer ID (begins with C, e.g. C03az79cb). This is your Cloud Identity / Workspace customer ID.
3. GCP_WORKSPACE_ADMIN_EMAIL — Only required for the Cloud Identity Users endpoint. The email of a Workspace admin the service account will impersonate via DWD. Skip this if you’re not enabling Cloud Identity Users.

​

Step 2: Create the service account

1. Open https://console.cloud.google.com/iam-admin/serviceaccounts
2. Pick (or create) a project to host the service account — configview-integration is conventional, but any project the SA can use as its “home” works
3. Click Create Service Account
4. Name: configview
5. Click Create and Continue — we’ll add roles in the next step
6. Click Done (you can skip the optional grant-users step)

​

Step 3: Grant the service account org-level roles

No billing export, no cost data. GCP has no cost API — detailed spend only exists if you’ve enabled Billing → BigQuery export (Standard + Detailed usage cost, and optionally Pricing). If you haven’t, set it up first (console → Billing export), then point ConfigView at it via the secrets in Step 5. Budgets and the account→project map work without the export.

About Cloud Asset Viewer. This role alone covers most of the heavy lifting. If you want a single-role install and don’t mind slightly less granular reads, you can grant roles/cloudasset.viewer + roles/browser and the majority of the 27 endpoints will function. The other roles fix the gaps for billing, service-usage, IAM policy, and SA keys.

Cloud Identity Users needs no org role. That endpoint reads the user directory through the Admin Directory API via domain-wide delegation (Step 6), not a GCP IAM grant — so there’s nothing to add here for it. (There is no roles/cloudidentity.viewer; the predefined Cloud Identity roles are roles/cloudidentity.groups.readonly and friends, none of which this integration uses.)

​

Step 4: Create + upload the JSON key

1. From the service account list, click your configview service account
2. Open the Keys tab → Add Key → Create new key → JSON
3. Click Create — the JSON file downloads automatically
4. Upload the JSON to your ConfigView satellite at <satellite-root>/json/google_cloud.json (your ConfigView administrator can do this — it’s NOT a Secret Manager secret because the file is bigger and is referenced directly by all scripts)

Where the file lives. The scripts resolve <project_root>/json/google_cloud.json, where <project_root> is the dashboard-backend root. On a satellite this is /opt/configview-dashboard-backend/json/google_cloud.json — the same directory that already holds secret-manager.json and google_admin.json. Permissions: chmod 400, owner configview:configview.

​

Step 5: Add the secrets to ConfigView

1. Go to your ConfigView dashboard: https://{companyname}.configview.com/admin/secret/
2. Click Add Secret and create:
   • GCP_ORG_ID: from Step 1.1 (numeric, e.g. 123456789012)
   • GCP_CUSTOMER_ID: from Step 1.2 (starts with C)
   • GCP_WORKSPACE_ADMIN_EMAIL: from Step 1.3 (admin email to impersonate, only needed for Cloud Identity Users)
3. For the billing detail endpoints, also add (skip if you’re not enabling cost/pricing/budgets):
   • GCP_BILLING_BQ_PROJECT: the project that holds the BigQuery billing export (e.g. my-billing)
   • GCP_BILLING_BQ_DATASET: the dataset name within it (e.g. billing)
   • GCP_BILLING_ACCOUNT_ID: the billing account ID with dashes (e.g. 01ABCD-23EFGH-45IJKL)
   • (optional) GCP_BILLING_DETAILED_DAYS (default 7), GCP_AUDIT_LOOKBACK_HOURS (default 24), GCP_AUDIT_MAX_ENTRIES (default 100000)
4. Click Save

​

Step 6: Domain-Wide Delegation (only for Cloud Identity Users)

1. From the service account list, click your configview SA → Details → expand Advanced settings → copy the Client ID
2. Sign in to your Google Workspace admin console as a super admin: https://admin.google.com
3. Go to Security → Access and data control → API controls → Manage Domain Wide Delegation
4. Click Add new and paste:
   • Client ID: (from above)
   • OAuth scopes: https://www.googleapis.com/auth/admin.directory.user.readonly
5. Click Authorize

​

Step 7: Enable the Google Cloud scripts

1. Go to: https://{companyname}.configview.com/admin/cron/
2. You should see google-cloud in the list of available apps
3. Enable scripts by tier — turn on the parents first; children will run automatically after them:

​

Identity & governance

​

Compute — core inventory

​

Compute — cost & waste

​

Compute — security & network posture

​

Compute — fleet shape & load balancing

​

Storage & data

​

Security

​

Cost & billing

4. Click Save

​

Step 8: Verify

1. Go to: https://{companyname}.configview.com/admin/cron/
2. Expand google-cloud and click the Health check button on the app header
3. A passing run reports overall: ok. On failure, the toast lists the failing checks — and the same result is written to the Activity log and emailed to your alert address. The health check also runs automatically right after any google-cloud script fails, so failures are captured even if you don’t trigger it by hand.
4. Projects, Organizations, and at least one Asset-API endpoint (e.g. Compute Instances) should pass

• PERMISSION_DENIED on Asset API — roles/cloudasset.viewer not granted at the organization level (project-level isn’t enough). Re-do Step 3 against the org.
• SERVICE_DISABLED: <API> has not been used in project X — That API isn’t enabled on the SA’s host project (X is the project number). Applies to cloudasset, cloudresourcemanager, cloudbilling, and iam — enable the full set from the Prerequisite at the top. Calls are billed/quoted against the SA’s host project, not the org. Expect intermittent SERVICE_DISABLED for ~10–15 min after enabling while it propagates.
• PERMISSION_DENIED on Service Usage — Missing roles/serviceusage.serviceUsageViewer.
• PERMISSION_DENIED on billing — Missing roles/billing.viewer. Billing is granted at the billing account level, not org level, depending on your account structure.
• PERMISSION_DENIED on Service Account Keys — Missing roles/iam.securityReviewer OR the customer turned off SA key listing via org policy (constraints/iam.disableServiceAccountKeyCreation is unrelated; the relevant constraint is on read).
• unauthorized_client: Client is unauthorized to retrieve access tokens on Cloud Identity Users — DWD client ID not authorized, or wrong scope. Re-do Step 6.
• Billing cost/pricing returns Access Denied or Not found: Table — the SA is missing roles/bigquery.dataViewer on the billing-export project or roles/bigquery.jobUser on its own project, or a GCP_BILLING_* secret is wrong (project/dataset/account ID). Confirm the export table exists: bq ls <project>:<dataset>.
• Audit Logs returns few/no rows — roles/logging.viewer must be at the org so it covers all projects; Admin Activity is always on, but check the GCP_AUDIT_LOOKBACK_HOURS window. Transient 500 Internal error on entries.list is retried and bad projects are skipped automatically.

​

Data Tables

• additional_attributes_json — Cloud Asset’s search index. A small, type-specific set of fields it chose to index (a Disk gets type, sizeGb, users; a Route gets id and nothing else). Fast, but mostly absent.
• resource_json — the full resource body, exactly as the Compute API would return it. This is where destRange, expireTime, resourcePolicies, endTimestamp and everything else actually lives.

​

What you can’t ingest with this setup

• Data Access / System Event / Policy Denied audit logs. Only Admin Activity audit logs are ingested (config changes). Data Access logs are off by default, very high volume, and not pulled in this version.
• Per-resource detailed metrics (CPU, network throughput, etc.). The Asset API gives configuration + metadata. Real-time metrics live in Cloud Monitoring.
• GCS bucket object listings. Buckets yes; objects no — that would multiply the row count by many orders of magnitude.
• Secret Manager secret payloads. ConfigView reads names and metadata only. Payloads stay in GCP.
• Compute Engine quota usage. Per-project and per-region quota limits and current usage come from compute.projects.get / compute.regions.list, which are not Cloud Asset types — they need a separate collector that walks every project. Not built yet.
• Google’s own catalogs — machine types, disk types, accelerator types, zones, regions, interconnect locations. These are identical for every customer and reference data rather than inventory, so they are deliberately not ingested. SKU-level rates come from the billing pricing export instead.
• Compute operations logs (globalOperations, regionOperations, zoneOperations). Resource-change churn is already covered by the Admin Activity audit log endpoint.