Google Cloud Bigtable

Google Cloud Bigtable is a fully managed, wide-column NoSQL database for large analytical and operational workloads. Relyance AI connects to Bigtable to discover and classify the personal and sensitive data held in its tables.

What you'll need

• A Google Cloud service account Relyance can impersonate, in the project holding the Bigtable instances.
• The Project ID of that project.
• The instance IDs you want scanned.

Permissions Relyance needs

Grant the service account a role carrying these two permissions on the project:

Relyance also reads instance and cluster metadata (bigtable.get_instance, bigtable.list_instances, bigtable.list_clusters) and Cloud Monitoring time series (monitoring.query_time_series) to size the scan, so the role needs read access to those as well — roles/bigtable.reader plus roles/monitoring.viewer covers everything above.

In Google Cloud

1. Create a service account in the project holding the Bigtable instances, following the naming convention rely-<tenant_name>-int-<suffix>.
2. Grant it the roles above on that project.
3. Allow Relyance to impersonate it: on the service account's Principals with access tab, grant Workload Identity User to tenant-gcp-integrations@relyance-prod.iam.gserviceaccount.com. This is the same impersonation grant as the Google Cloud Platform integration — no key file is created or downloaded.

In the Relyance AI application

1. Log in to your Relyance account.
2. Navigate to Settings › Integrations and find the Google Cloud Bigtable card.
3. Click Add Connection, give it a name, and click Add.
4. On the Overview step, select the features you want and click Continue.
5. On the Connection step, set the rescan frequency and any Business Atlas associations, then click Continue.
6. On the Authentication step, choose Instance Scan under Authentication Method — it is the only method Bigtable offers — and provide:

   • Service Account Email — the account created above, e.g. rely-<tenant_name>-int-<suffix>@<your-project-id>.iam.gserviceaccount.com

   • Project ID to scan

   • Instance Configuration (optional) — which instances and tables are in scope. instance_id names the instance; the allow list wins where both are set:

     [
       {
         "instance_id": "",
         "allow_tables": [""],
         "block_tables": [""]
       }
     ]

7. Click Authenticate, then Finish on the Completion step.
8. Confirm the connection shows Connected.

Verify the connection is really working

1. A failure at Authenticate is almost always the impersonation grant from step 3 — check Workload Identity User is on the service account itself, not on the project.
2. After the first scan, confirm the instances you expected appear as assets. Fewer than expected usually means the roles were granted in a different project, or an instance is excluded by the Instance Configuration.
3. Tables present but no data types classified points at bigtable.tables.readRows — listing works without it, reading does not.

Manage this integration with Terraform

Connections for this integration can be managed as code with the Relyance Terraform provider. Non-secret fields go in auth.params; secret fields go in auth.secrets_wo, which is write-only — never stored in Terraform state. Rotate secrets by bumping auth.secrets_wo_version.

resource "relyance_integration_connection" "gcloud_bigtable" {
  vendor = "gcloud_bigtable"
  name   = "<your connection name>"

  auth = {
    method = "service-account"
    # Secret fields are write-only: sent to Relyance, never stored in state.
    secrets_wo = {
      service_account_email = var.gcloud_bigtable_service_account_email
      project_id_scan = var.gcloud_bigtable_project_id_scan
    }
    secrets_wo_version = 1
  }

  scans = { "data-inspection" = { enabled = true } }
}