See the automated setup for a Python script to set everything up, or follow the standard guide below.
Prerequisites
Permissions
A user with the following roles is needed to complete this setup:
- Billing Account Costs Manager or Billing Account Administrator.
- Organization Admin (or another role that includes
resourcemanager.organizations.setIamPolicy)
Enabled APIs
Ensure the following APIs are enabled on the project that will host the billing dataset and service account:
bigquery.googleapis.comiam.googleapis.comiamcredentials.googleapis.comcloudresourcemanager.googleapis.com
Enable TABLE_STORAGE_BY_ORGANIZATION
SELECT uses INFORMATION_SCHEMA.TABLE_STORAGE_BY_ORGANIZATION to provide storage visibility across your org. This view must be explicitly enabled for each region where your BigQuery data resides.
First, discover all regions in use across your organization by running this in Cloud Shell:
This outputs an ALTER ORGANIZATION statement for each region. Paste and run the output in BigQuery Studio as a user with the roles/bigquery.admin role. For example, if your org has data in US and EU the output would be:
Note: Allow up to 24 hours for historical data to become available after enabling. SELECT will not be able to display storage data until this step is complete.
Connecting your account
There are two components of setup. Firstly, enabling the billing data exports, and secondly granting SELECT read access to BigQuery and the exported data.
For the setup, you can use an existing project, or create a new one dedicated to the Select.
For the rest of this guide, we'll use customer-billing-project to refer to the project that will host both the billing export dataset and the service account SELECT uses.
Step 1: Enable billing exports
SELECT needs three billing exports (usage, pricing, and committed use discounts) to give you complete cost visibility. Each are written to BigQuery, and should be configured to land in the same dataset.

- In the Google Cloud Console, navigate to Billing. You will be redirected to the Cloud Billing account page.
- In the left pane, click Billing export.
- Follow the three next steps.
1a. Detailed usage cost export

- On the BigQuery export tab, find Detailed usage cost and click Enable detailed export.
- For Project, select
customer-billing-project. - For the dataset, click create new dataset:
- It's important to create a dataset specific to SELECT so you can limit SELECT's access to just the billing data.
- Enter a dataset ID of your choosing (e.g.
billing_export). Note this down, you'll need it later. - Choose a multi-region location (
USorEU).
- Click Save.
1b. Pricing data export
- Back on the Billing export page, find Pricing data and click Enable pricing export.
- Select the same project and dataset as in 1a.
- Click Save.
1c. Committed use discount (CUD) data export
- Find Committed use discount data and click Enable CUD export.
- Select the same project and dataset as in 1a.
- Click Save.
It can take up to 24 hours for the first batch of billing data to appear.
Step 2: Create the custom org role
Rather than binding multiple predefined roles separately, create a single custom role at the org level that consolidates all permissions SELECT needs. This gives you one binding to manage and makes it easy to audit exactly what access SELECT has.
This custom role combines the permissions from three predefined roles — roles/bigquery.resourceViewer, roles/bigquery.metadataViewer, and roles/browser — plus the single additional permission bigquery.config.get, which is required to detect fluid scaling on BigQuery reservations and is not included in any predefined role.
Step 3: Create the service account
In your project UI navigate to IAM → Service Accounts → Create Service Account and give it a name, e.g. select-viewer. Click Create and continue, then skip the optional role and group steps and click Done.
Alternatively, in Cloud Shell or any environment with gcloud authenticated:
This creates the service account select-viewer@${CUSTOMER_PROJECT}.iam.gserviceaccount.com. Note this email down — you'll need it in the final step.
Now attach the custom role you created in Step 2, plus project-level roles to allow SELECT to run queries and use read sessions:
Step 4: Grant read access to the billing dataset
Grant bigquery.dataViewer scoped to only the billing export dataset. This ensures SELECT has no access to your company's data.
In BigQuery Studio, navigate to the billing export dataset you created.
Click Share> Manage Permissions.
Click Add principal.
Add select-viewer service account.
Assign roles BigQuery Dataset Viewer.

Alternatively, In Cloud Shell or any environment with gcloud authenticated:
Step 5: Allow SELECT to impersonate the service account
SELECT's backend service account ([email protected]) authenticates by impersonating the service account you just created. No passwords or keys required.
Go to IAM & Admin → Service Accounts in the project.
Find select-viewer@... in the list.
Check the box next to it.
On the right side, click Manage Access.
Click Add Principal.
Enter [email protected] as the principal
Select role Service Account Token Creator
Save


Alternatively, In Cloud Shell or any environment with gcloud authenticated:
Add connection to SELECT

- Navigate to the connections tab in SELECT's settings.
- Click the Add Connection button.
- Enter a connection name (e.g. your organization's name), and fill out all the details from the previous steps:
- Project ID (e.g.
customer-project) - Billing export dataset name (e.g.
billing_export) - Billing Account ID (eg.
ABCDEF-12345-67810)
- Project ID (e.g.
- Click Add. SELECT will run a test query to verify the connection.
That's it! Hold tight and you'll receive an email when the initial sync is complete, usually within a couple of hours.
If your BigQuery project is inside a VPC SC perimeter, you will see this error when adding the connection in Select.dev:
VPC Service Controls: Request is prohibited by organization's policy.vpcServiceControlsUniqueIdentifier: <unique-id>
Follow the steps below to resolve it.
VPC Service Controls (optional)
If your GCP organization has VPC Service Controls enabled with a service perimeter around BigQuery, SELECT's queries will be blocked by default. You'll need to explicitly allow SELECT through the perimeter. Only follow these steps if your organization uses VPC Service Controls.
Recommended: Allow by service account identity
Since SELECT authenticates by impersonating your select-viewer service account, the most reliable approach is an ingress rule scoped to SELECT's backend service account ([email protected]). This is more robust than IP-based allowlisting as it doesn't depend on network routing.
Create an ingress rule YAML file:
Why ANY_IDENTITY and not a specific service account?
Select's backend service account ([email protected]) is in a different GCP organization than your VPC SC perimeter. VPC SC's ANY_SERVICE_ACCOUNT identity type only matches service accounts within the same organization as the perimeter — it will never match a cross-org SA. ANY_IDENTITY is required to cover cross-org service accounts.
This is still secure because:
- The source is locked to Select's project (
813120990659) — no other GCP project can use this rule - IAM enforces that only
[email protected]can impersonate yourselect-viewerSA - Your
select-viewerSA has read-only BigQuery permissions only
Apply it to your service perimeter:
Alternative: Allow by IP address
- ⚠️ IP allowlisting will not work for most customers. Select.dev runs on Google Cloud Run, which routes all traffic through Google's internal network. GCP redacts the source IP to
gce-internal-ipfor all Cloud Run traffic, meaning IP-based access levels will never match the request. Google's own documentation recommends ingress rules over IP-based access levels for this reason. Only use IP allowlisting if you are connecting via a self-hosted proxy that preserves the source IP.
Note: Always test perimeter changes in dry-run mode before enforcing them to avoid accidentally blocking other services. See Google's VPC SC dry-run documentation for details.



