Google BigQuery Row-Level Security

Row-level Security (RLS) is a fine-grained access control mechanism that restricts which rows of data a principal can access within a BigQuery table. BigQuery implements this using Row Access Policies (RAPs).

A Row Access Policy is a table-level object that filters rows at query time based on two components:

• A Grantee List: the Google Principals (users, Google Groups, etc.) to whom the Policy applies.
• A Filter Expression: an SQL predicate that determines which rows are visible to the granted principals.

Row Access Policies provide dynamic, identity-aware filtering without modifying the underlying data, so users only see rows they're authorized to access.

For general Native Policy concepts that Row-level and Column-level Policies share (the Native tab, the Protected Resource sub-tab, and how Vendor Compare deploys changes to BigQuery), see Google BigQuery Native Support.

Viewing Row-level Policies in PlainID

PlainID displays Row-level Policies in Native mode.

To view a Row-level Policy in Native:

1. In the Policies Workspace, select the relevant Policy connected to Google BigQuery.
2. On the top navigation bar, click Native.
3. The Native Code panel displays the Policy Core Logic and Identities Link sections for the Row-level Policy, described in Policy Core Logic and Identities Link below.

Asset Type Requirements for Row-level Policies

Discovery creates the Asset Type for a BigQuery table automatically, and Manage Mode reuses that same Asset Type when you build a Row-level Policy. You don't need to create or configure an Asset Type yourself. During discovery, the Platform:

• Names the Asset Type using the BigQuery resource format: project_ID.dataset.table_name.
• Maps Asset Attribute names exactly to BigQuery column names, which are case-sensitive.
• Marks the Asset Type as used for data filtering.
• Excludes JSON columns from the Asset Type, since BigQuery Row Access Policies don't support filtering on JSON column types.

Creating a Row-level Policy from Native

You can create new Row-level Policies for Google BigQuery directly from their native structure. There are three steps when you create a Policy:

• Details
• Code
• What

This POP has no Wizard-based creation path. You can only create it through Native.

Details Step:

1. From the Create Policy drop-down, select From Native.
2. On the Policy Details step, input a:

• Display Name
• Change the Policy ID if required
• Enter an optional description

3. The Access Type is fixed to Allow. BigQuery Row Access Policies only grant visibility into rows, so there's no restrictive option to choose here.

4. In the Google POP Details section, under the Vendor Policy Kind dropdown, choose Row Access Policy.

5. Enter a Vendor Policy Name.

6. Input the following.

   • Project ID: inherited from the POP's Service Account JSON of the selected application (no input required).
   • Dataset ID: select from the datasets discovered by the POP.
   • Table ID: select from the tables discovered for the selected dataset.

7. Input the custom details if applicable to your Policies (optional).

8. Click Continue.

Code Step:

In the Code step, input the logic and relevant links. Replace the placeholder with the intended filter logic. Each section includes its predefined structure and a logic placeholder, for example:

{
  "filterPredicate": "{{logic placeholder}}"
}

A Row-level Native Policy in BigQuery consists of two sections: Policy Core Logic and Identities Link.

Policy Core Logic

The Policy Core Logic defines the SQL filter predicate that determines which rows are visible to the granted principals.

{
  "filterPredicate": "<sql_filter_expression>"
}

Examples:

Simple condition:

{
  "filterPredicate": "region = 'EMEA'"
}

Compound condition:

{
  "filterPredicate": "col1 = 'one' AND (col2 = 'two' OR col3 = 'three')"
}

Subquery using SESSION_USER():

{
  "filterPredicate": "col1 IN (
    SELECT
      col2
    FROM
      `plainid-orchestration.name_dataset.nametable6`
    WHERE
      col2 = SESSION_USER()
  )"
}

JOIN subquery:

{
  "filterPredicate": "col1 IN (
    SELECT
      t10.col4
    FROM
      `plainid-orchestration.name_dataset.nametable9` AS t9
      JOIN
      `plainid-orchestration.name_dataset.nametable10` AS t10
      ON t9.col2 = t10.col3
  )"
}

Field Reference

Identities Link

The Identities Link defines the grantee list: the Google Principals to whom the Row Access Policy applies.

{
  "grantees": ["<principal_1>", "<principal_2>"]
}

Example:

{
  "grantees": ["serviceAccount:bq-emea-reader@plainid-orchestration.iam.gserviceaccount.com"]
}

All supported grantee types:

{
  "grantees": [
    "allAuthenticatedUsers",
    "domain:plainid.com",
    "group:qa@plainid.com",
    "serviceAccount:bq-learn-research@acme-orchestration.iam.gserviceaccount.com",
    "user:name@acme.com"
  ]
}

Field Reference

Supported principal types:

What Step

In the What Step, add the relevant table as an Asset Type. Ensure it's the same table you set as the Table ID in the Details step.

Deploying Policy Changes

When you discover or edit a Row-level Policy in Manage Mode, PlainID doesn't push the changes to BigQuery automatically. Use the Policy Deploy operation to:

• Accept the vendor's version of a single Policy, discarding the pending Platform change.
• Accept the Platform's version of a single Policy, or all pending Policies, and push the update to BigQuery.

The Platform marks discrepancies between the vendor and Platform versions of a Policy, and you can review them side by side in Vendor Compare. For general information on how the Native tab, Protected Resource linking, and Vendor Compare work, see Google BigQuery Native Support.

Known Limitations