Google Cloud

Rivia connects to a GCP project through a service account that you create in your own project. Rivia has no Google Cloud presence of its own, so there is nothing on our side for that account to trust.

Every role below is read-only. Unlike the other clouds, this is true without exception: no GCP collector calls a mutating API, not even indirectly.

:::note Not switched on yet The setup on this page is complete and the in-app wizard generates it, but the Google Cloud tile is still disabled while we verify the collectors against a real project. If you want GCP now, follow this page and tell us, and we will enable it for your team. :::

What Rivia asks for

Four roles at project scope, plus two more only if you want cost data.

Role	Scope	What it reads	Required
roles/viewer	Project	Resource configuration and metadata	Yes
roles/iam.securityReviewer	Project	IAM policy on every resource	Yes
roles/storage.objectViewer	Project	Object contents in Cloud Storage	Yes
roles/recommender.viewer	Project	Google's own recommendations	Yes
roles/bigquery.dataViewer	Billing export project	The billing export table	Optional
roles/bigquery.jobUser	Billing export project	Permission to run the query	Optional

Two of these deserve the scrutiny.

roles/storage.objectViewer reads the contents of your buckets, not just their configuration. That is how Rivia finds unprotected PII, PHI, card data and secrets sitting in Cloud Storage. It is read-only, and it is the most sensitive thing on this page.

roles/iam.securityReviewer is not a superset of Viewer's powers, it is a narrower one: it grants getIamPolicy across resource types and nothing else. Viewer alone exposes only the project-level policy, which is not enough to work out who can actually reach a given resource.

roles/bigquery.jobUser looks like a write grant and is not. BigQuery accounts for a read as a job, so querying your billing export requires permission to create one. It confers no access to any data by itself.

We do not ask for roles/artifactregistry.reader. Container image scanning would need it to pull layers, and Rivia does not pull images from GCP yet, so asking for it now would be a permission we never use.

Enabling the APIs

This step has no equivalent on AWS or Azure, and skipping it is the most common way a GCP connection ends up half-working.

On GCP an API stays off until somebody turns it on. A service account with every role on this page still gets SERVICE_DISABLED against a project where, say, compute.googleapis.com was never enabled, and that failure surfaces at your first sync rather than during setup. Rivia reports the specific API and the command to fix it, but it is easier to enable them up front.

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  iam.googleapis.com \
  compute.googleapis.com \
  storage.googleapis.com \
  container.googleapis.com \
  sqladmin.googleapis.com \
  cloudfunctions.googleapis.com \
  dns.googleapis.com \
  artifactregistry.googleapis.com \
  recommender.googleapis.com \
  --project <PROJECT_ID>

Add bigquery.googleapis.com if you are connecting a billing export.

1. Create the service account

gcloud iam service-accounts create rivia-collector \
  --display-name="Rivia collector (read-only)" \
  --project <PROJECT_ID>

2. Grant the read-only roles

SA=rivia-collector@<PROJECT_ID>.iam.gserviceaccount.com

for ROLE in \
  roles/viewer \
  roles/iam.securityReviewer \
  roles/storage.objectViewer \
  roles/recommender.viewer
do
  gcloud projects add-iam-policy-binding <PROJECT_ID> \
    --member="serviceAccount:$SA" --role="$ROLE" --condition=None
done

3. Cost data, if you want it

Only if you have a BigQuery billing export configured. Grant these on the project that holds the export dataset, which is often not the project being scanned:

gcloud projects add-iam-policy-binding <BILLING_EXPORT_PROJECT_ID> \
  --member="serviceAccount:$SA" --role=roles/bigquery.dataViewer
gcloud projects add-iam-policy-binding <BILLING_EXPORT_PROJECT_ID> \
  --member="serviceAccount:$SA" --role=roles/bigquery.jobUser

Decline this and everything except cost reporting works normally.

4. Create a key

gcloud iam service-accounts keys create rivia-key.json --iam-account="$SA"

Paste the contents of rivia-key.json into Rivia along with the project ID, then delete your local copy. Rivia stores the key encrypted, never in plain text and never in logs.

Service account keys

If your organization enforces constraints/iam.disableServiceAccountKeyCreation, this step fails by design, and that is a reasonable policy to have: a service account key is a long-lived credential with no expiry.

Workload Identity Federation is the answer, and Rivia does not implement it yet, so a project under that constraint cannot be connected today. Tell us if this affects you; it moves up the queue on demand.

Connecting more than one project

Create the service account once, then grant it the same roles on each additional project:

for PROJECT in <PROJECT_ID_1> <PROJECT_ID_2>; do
  gcloud projects add-iam-policy-binding "$PROJECT" \
    --member="serviceAccount:$SA" --role=roles/viewer --condition=None
  # …and the other three roles
done

Each project becomes its own connection in Rivia, so you can see them separately and disconnect one without touching the others. Remember to enable the APIs on every project, not just the first.

What Rivia collects

Compute instances, disks and networks; Cloud Storage buckets; GKE clusters; Cloud SQL instances; Cloud Functions; DNS zones; Artifact Registry repositories; and IAM service accounts, roles and policy bindings. On top of that inventory it runs configuration security checks, classifies data in Cloud Storage, computes effective permissions per principal, reconciles Google's own recommendations, and ingests your billing export if you connected one.

One thing to be clear about: the GCP disk, function and container "scanners" derive findings from that inventory rather than from the resources themselves. They will tell you a disk has no customer-managed encryption key. They do not open the disk and look for CVEs.

Verifying and revoking

To see what the service account can reach:

gcloud projects get-iam-policy <PROJECT_ID> \
  --flatten="bindings[].members" \
  --filter="bindings.members:$SA" \
  --format="table(bindings.role)"

To revoke everything, delete the service account. Access stops immediately.

gcloud iam service-accounts delete "$SA"

Related

• AWS
• Azure