Skip to main content

Access Control

Starlake provides three levels of declarative security applied automatically at each load:

  • Table-level ACL -- Grant roles to users, groups or service accounts.
  • Row-level security (RLS) -- Filter rows with SQL predicates per grantee.
  • Column-level access policies -- Restrict access to PII columns (BigQuery only).

All three levels are combinable in a single table YAML definition. This declarative approach eliminates the need for manual security configuration after each deployment.

For excluding sensitive columns from ingestion entirely, see also the ignore attribute as an alternative to column-level security.

How to configure access control

  1. Open the table YAML file -- Edit metadata/load/<domain>/<table>.sl.yml.
  2. Add an acl section -- Define roles and grants for table-level access.
  3. Add an rls section -- Define row-level security policies with SQL predicates.
  4. Add accessPolicy on attributes -- Restrict specific columns (BigQuery only).
  5. Run the load -- Execute starlake load to apply the security configuration to the target table.

Table-level security (ACL)

The acl section grants roles to users, groups or service accounts. The syntax differs between BigQuery and Spark/Databricks.

BigQuery uses role-based access with typed grant identifiers:

table:
...
acl:
- role: role/bigQueryViewer
grants:
- user:[email protected]
- group:[email protected]
- serviceAccount:[email protected]
  • role: BigQuery role format (e.g., role/bigQueryViewer).
  • grants: Prefixed with user:, group: or serviceAccount:.

Row-level security (RLS)

RLS policies restrict which rows a user or group can see. Each policy defines a SQL predicate evaluated for every row. If the predicate evaluates to true, the row is visible to the grantees. If false, the row is hidden.

table:
...
acl:
- role: SELECT
grants:
- [email protected]
- group
rls:
- name: "USA only"
predicate: "country = 'USA'"
grants:
- "group:mygroup"

In this example, members of group:mygroup only see rows where country = 'USA'.

Column-level security (BigQuery only)

Column-level security uses BigQuery access policies to restrict access to specific columns. Set the accessPolicy property on sensitive attributes.

table:
...
attributes:
- name: "code0"
accessPolicy: PII
type: "string"
...

This restricts the code0 column to users with the appropriate BigQuery access policy. Non-authorized users see NULL instead of the actual value.

Full example: ACL + RLS + Column-level security

table:
...
acl:
- role: SELECT
grants:
- [email protected]
- group
rls:
- name: "USA only"
predicate: "country = 'USA'"
grants:
- "group:mygroup"
attributes:
- name: "code0"
accessPolicy: PII
type: "string"
...

Frequently Asked Questions

How do I define access rights on a table in Starlake?

Use the acl section in the table YAML definition. Specify a role (permission) and a list of grants (users, groups or service accounts).

How do I configure Row Level Security (RLS) in Starlake?

Add an rls section in the table definition. Each RLS policy contains a name, a predicate (SQL expression evaluated for each row) and grants defining the beneficiaries.

Is Column Level Security supported on all warehouses?

No. Column Level Security is supported on BigQuery only. It uses BigQuery access policies to restrict access to specific columns.

How do I protect a column containing PII in Starlake?

Add the accessPolicy: PII property on the attribute in the table definition. This feature uses BigQuery access policies.

What is the ACL syntax for BigQuery in Starlake?

The role uses the BigQuery format (e.g., role/bigQueryViewer). Grants use the format user:, group: or serviceAccount: followed by the identifier.

What is the ACL syntax for Spark/Databricks in Starlake?

The role corresponds to a SQL permission (e.g., SELECT). Grants are user or group identifiers without a type prefix.

Can I combine ACL, RLS and Column Level Security on the same table?

Yes. All three security levels can be combined in the same table YAML definition.