This article describes how to configure and create a Google BigQuery Policy Orchestration Point (POP) in the Platform.
Prerequisites
Before you create a Google BigQuery POP, complete the following steps in the customer's Google Cloud project. If you skip these steps, the POP test connection fails.
Enable Required Google Cloud APIs
The PlainID BigQuery connector validates the connection using an IAM-based flow: it reads the project IAM policy to find the roles assigned to the tested Service Account, then expands those roles into the permissions they include. This flow depends on two Google Cloud APIs that the project does not enable by default.
Enable both of the following APIs in the customer's GCP project:
| API | Service Name | Used For |
|---|---|---|
| Cloud Resource Manager API | cloudresourcemanager.googleapis.com |
Reading the project IAM policy (resolving which roles are assigned to the Service Account) |
| Identity and Access Management (IAM) API | iam.googleapis.com |
Reading role definitions (expanding assigned roles into their included permissions) |
To enable the required Google Cloud APIs, enable the IAM API in the Google Cloud Console or the gcloud CLI, then run a verification check to confirm both APIs are active.
GCP Service Account
PlainID connects to Google BigQuery using a GCP Service Account. A Service Account is a non-human identity used for server-to-server integrations and does not require human sign-in.
To set up a GCP Service Account for PlainID:
- In GCP IAM, create a dedicated Service Account for PlainID.
- Grant the Service Account the required IAM permissions (see Required IAM Permissions below).
- Create a new JSON key for the Service Account. Ensure that you keep it secure. See below for more information.
- Download the key file. This file is the credential used when configuring the POP.
Authentication Method: Service Account
PlainID uses Service Account authentication to establish a secure, automated integration with Google BigQuery.
The Service Account JSON key file has the following structure:
{
"type": "service_account",
"project_id": "your-gcp-project-id",
"private_key_id": "...",
"private_key": "-----BEGIN PRIVATE KEY-----\n...",
"client_email": "plainid-pop@your-gcp-project-id.iam.gserviceaccount.com",
"client_id": "...",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token"
}
The Service Account JSON key contains sensitive cryptographic material. PlainID stores this credential securely. Never share or expose the key file outside of this configuration flow.
Required IAM Permissions
The Service Account must have specific GCP IAM permissions. PlainID recommends creating a custom IAM role following the principle of least privilege, rather than assigning broad roles such as Owner or Editor.
Test Connection Prerequisites
Regardless of mode, the Service Account needs the following permissions so the connector can inspect its own assigned roles:
| Permission | Purpose |
|---|---|
resourcemanager.projects.getIamPolicy |
Check the IAM permissions granted to the Service Account on the project |
iam.roles.get |
Retrieve role definitions to validate effective permissions |
Permissions for Learn Mode
Learn Mode scans and discovers existing relevant Google BigQuery objects, such as Datasets, Tables, Columns, Taxonomies, and Policies. The following permissions are required:
| Permission | Purpose |
|---|---|
bigquery.datasets.get |
List Datasets and view their metadata |
bigquery.tables.list |
Enumerate Tables and Views within Datasets |
bigquery.tables.get |
Retrieve table schemas and discover attached Policy Tags |
bigquery.rowAccessPolicies.list |
Discover existing Row Access Policies on tables |
bigquery.rowAccessPolicies.getIamPolicy |
Retrieve the IAM policy (grantees) for each Row Access Policy |
bigquery.dataPolicies.list |
Discover Data Policies associated with Policy Tags |
bigquery.dataPolicies.getIamPolicy |
Retrieve the IAM bindings (masked/unmasked readers) for each Data Policy |
bigquery.routines.get |
Retrieve custom UDF definitions used in masking policies |
datacatalog.taxonomies.get |
View existing Policy Tag Taxonomies |
datacatalog.taxonomies.list |
List all Taxonomies in the target project and location |
Additional Permissions for Manage Mode
Manage Mode allows PlainID to deploy and update Policies in BigQuery. The following permissions are required in addition to the Test Connection Prerequisites and Learn Mode permissions:
| Permission | Purpose |
|---|---|
bigquery.rowAccessPolicies.get |
Read an individual Row Access Policy |
bigquery.rowAccessPolicies.create |
Create new Row Access Policies |
bigquery.rowAccessPolicies.update |
Modify existing Row Access Policies |
bigquery.rowAccessPolicies.delete |
Remove Row Access Policies |
bigquery.rowAccessPolicies.setIamPolicy |
Manage the filteredDataViewer IAM binding on Row Access Policies |
bigquery.tables.getData |
Required by BigQuery for Row Access Policy DDL operations |
bigquery.tables.update |
Attach Policy Tags to columns (schema modification) |
bigquery.jobs.create |
Run DDL jobs for Policy deployment |
bigquery.dataPolicies.get |
Read an individual Data Policy |
bigquery.dataPolicies.create |
Create a Data Policy linking a Policy Tag to a masking rule |
bigquery.dataPolicies.update |
Modify an existing Data Policy |
bigquery.dataPolicies.delete |
Remove a Data Policy |
bigquery.dataPolicies.setIamPolicy |
Assign the maskedReader role to principals for a Data Policy |
BigQuery enforces strict regionality. Policy Tag Taxonomies are regional resources and you cannot apply them across regions. Ensure the Service Account has the required permissions in the specific GCP region where your datasets reside. If you have data in multiple regions, you may need to configure separate POPs per region.
Creating a Google BigQuery Policy Orchestration Point
After configuring the Service Account with the required IAM permissions, you can create a Google BigQuery Policy Orchestration Point (POP).
Ensure you have an Integration Workspace (previously Orchestration Workspace) before continuing.
To create a Google BigQuery POP:
- In the Environment side panel, click on the Integration Workspace (previously Orchestration Workspace), then click Add Policy Orchestration Point. The Select Vendor side panel opens.
- Select Google BigQuery. The POP configuration form opens.
- In the General section:
- Enter a Display Name for the POP. (Required)
- Enter a POP ID. (Required)
- Enter a Description. (Optional)
- Choose which mode you would like your POP to be in: Learn or Manage mode. For more information about either mode, refer to the Changing the POP Mode.
- In the Associated Workspaces section:
- Select an Identities Workspace. (Required)
- Select a Policies Workspace. (Required)
- In the Connection Settings section:
- Authentication Method is automatically set to Service Account and cannot be changed.
- Secret Store defaults to PlainID Internal SSM Parameter Store.
- Input your Project ID. (Required)
- This ID is validated against the Project ID in your Service Account JSON.
- Under Service Account JSON, click Import Service Account JSON to upload the Service Account JSON key file downloaded during prerequisite setup. (Required)
- Click Test Connection to verify that the Service Account has the required permissions and that the Platform can connect to Google BigQuery.
- If the connection test fails, an error appears indicating what needs to be resolved.
- When the test connection is successful, click Create. The POP is added to the Integration Workspace, and an initial discovery is triggered.
Discovery Scope and Behavior
After you create the POP, PlainID triggers an initial Discovery. The following objects are discovered from your Google BigQuery Environment:
| Object | Description |
|---|---|
| Dataset | A logical container for tables and views within a GCP Project. PlainID uses the Dataset as the top-level scope for discovery within the configured project. |
| Table | A structured data object within a Dataset. PlainID discovers tables and uses them as the target for Row-Level Policies. |
| View | A virtual table defined by a SQL query. Views are discovered automatically alongside tables. |
| Column | A field within a table or view. Columns with string or numeric data types are represented as Asset Attributes and can be used in Policy logic. Other data types are discovered but cannot be used in Policy rules. |
| Row Access Policy | A table-level security object that filters rows based on a SQL predicate and a grantee list. Discovered policies are mapped to PlainID Row-Level Policies. |
| Taxonomy | A hierarchical grouping of Policy Tags used for column-level classification. PlainID discovers Taxonomies to resolve Policy Tag names. |
| Policy Tag | A classification label within a Taxonomy attached to one or more columns. Used to enforce Column-Level Security. |
| Data Policy | A resource that links a Policy Tag to a masking rule and defines which principals receive masked or unmasked access. Discovered Data Policies are mapped to PlainID Column-Level Policies. |
| Routine (UDF) | A custom masking function referenced by a Data Policy. Discovered when a Data Policy uses a custom routine instead of a predefined masking expression. |
For more information on how discovered objects are mapped to Platform building blocks, refer to Google BigQuery Row-Level Security and Google BigQuery Column-Level Security.