Databricks Row-Level Security

Row-level security (RLS)

Row-level security (RLS) is a fine-grained access control mechanism that restricts which rows of data a user or group can access within a table or view. In Databricks, this is commonly implemented using Row Filters.

Row Filters are created as SQL user-defined functions (UDFs) and also incorporate logic from other languages (such as Python) when wrapped in a SQL UDF.

It provides fine-grained access control by dynamically filtering data through conditional expressions and identity functions such as is_account_group_member(group), is_member(group), or other Databricks identity functions.

Creating a Databricks Row Access Policy in PlainID

Row Access Policies in PlainID can be created using the following methods:

• Wizard
• Code
• Native

For more information, refer to Creating Policies.

To create a Row Access Policy with the Policy Wizard:

1. Fill in Policy Details. For more information, refer to the Creating Policies article

2. Select Use Policy For SaaS Applications and select the Databricks application.

3. Fill in Databricks POP Details specific to the vendor Policy:

   • Under Vendor Policy Kind dropdown, select Row Access Policy. (Required)

   • Under Vendor Policy Name, enter a unique name (in small letters) for the Policy that will appear in the Databricks vendor. (Required)

     • Note: The same name can be used across multiple PlainID Policies to define multiple logic statements within a single Databricks Row Access policy (UDF).

   • Under Vendor Policy ID, note that the ID is automatically generated. It is the ID used in Policy management operations like deploy, update, and override.

   • Under Vendor Policy Order, define the execution order for the logical case statement within the same Vendor Policy ID. (Required)

     • Default value is 1. Use this field when enforcing multiple logic conditions for different Identity Groups within the same Policy.

   • Under Comment, add any additional information or clarifications about your Policy. (Optional)

   • Under Catalog, select the Databricks catalog where the Policy will be deployed.

   • Under Schema, select the schema within the catalog where the Policy resides.

   • Ensure that your Databricks app in Orchestration is switched to Manage mode to start building your Row-level Policy in the Policy catalog section. See Managing POPs for more information on how to change the POP Mode.

4. Click Continue.

Who Section

In the Who section, you assign Row-level access by creating a new Dynamic Group or selecting an existing one. You can evaluate multiple Dynamic Groups (OR relationship between them) within a single Row Access Policy, enabling centralized and flexible access control logic.

Define a new Dynamic Group using the available vendor identity functions to grant access based on user identity parameters.

Supported Databricks identity functions include is_account_group_member(group), is_member(group), session_user(), and current_user().

You can use multiple identity functions per Dynamic Group.
To apply your Policy logic to all users, you can select the default "All Users" Dynamic Group.

What Section

In the What section, you can define access through your Asset Types.

Reusing Tables and Views

To apply different row filtering rules for different roles, groups, or context conditions, you can reuse the same Vendor Policy Name across multiple PlainID Row Access Policies.

This enables you to define multiple logical statements within a single Databricks Row Filter function (UDF), allowing flexible and centralized access control.

To define access:

1. Click Add Asset Type. Ensure that your Asset Type meets the requirements listed below

2. From the dropdown, select an Asset Type.

3. Select existing Rulesets for your Policy logic or create a new one. A Policy can include multiple Rulesets (OR relationship between them).

   • See Defining a Ruleset for Row-level Filtering for more information.

4. Click Save.

Asset Types for Row-Level Requirements

Ensure that your Asset Type/s meet the following requirements:

Table Mapping

To set Table Mapping:

1. In the Authorization Workspace, click on the Assets & Conditions tab.

2. Click on the relevant Asset.

3. Ensure that "Is used for data filtering?" is enabled.

4. Select Set Table Mapping to link your logical Asset Type with one or more physical Tables or Views in Databricks where the Row Access Policy should apply.

   • The mapping must include the fully qualified path (in lower-case) to the table or view, following the format:
     catalog_name.schema_name.table_name.

• These mappings are reusable and can support multiple policies.
• The mapping must match the Tables or Views that may be used in the policy.
• Only the Tables or Views explicitly selected in the Policy are protected by the Row Access Policy.

Attribute Mapping

To set Attribute Mapping:

1. Choose an existing Attribute or create a new one to use in your filtering logic.
2. Define the data type (for example, String, Numeric).
3. Enable Available for Policies = Yes. These attributes act as placeholders for filtering conditions.
4. Click Set Data Column Mapping to map the logical Attributes to one or more physical Databricks column/s (in lower-case).

Note: PlainID does not currently support ICEBERG Tables.

Table/View Asset Type Prerequisites

The Table/View Asset Type represents the physical Databricks tables or views that are protected by the Row Access Policy.

To use Table/View Assets in a Row Access Policy, the selected Asset Type must already be configured with a valid Table Mapping. This mapping defines the relationship between the logical Asset Type used in the policy and the physical Databricks tables or views that may be protected.

Only discovered Table/View Assets that match the Asset Type table mapping can be associated with the policy.

Table/View Assets

The Table/View Asset Type is automatically generated when the Databricks Policy Orchestration Point (POP) is created. It represents the discovered Databricks tables and views that can be protected by Row Access Policies.

These assets appear in the Assets section and are discovered from Databricks. Each asset represents a specific physical table or view.

When configuring a Row Access Policy, you select one or more of these discovered Table/View Assets to define which objects the policy protects.

Only the tables or views explicitly selected in the policy are secured by the Row Access Policy.

In order to use Table/View Assets within a Row Access Policy, the Asset Type’s Table Mapping must be predefined correctly. During translation, only mappings relevant to the selected protected Table/View Assets are used.

Discovery Behavior

As part of discovery, PlainID creates the Asset Type and connects the relevant Ruleset. In addition, the system discovers and associates one or more Table/View Assets that represent the protected objects. These discovered assets are available for selection in the Table/View Asset Type and are associated with the policy based on the defined mappings.

Notes:

• A policy can be associated with one or multiple protected assets.
• Both tables and views are supported.
• The term table in this article may refer to either a table or a view, depending on the discovered object.

To connect an Asset Type with the Databricks Application:

1. Once the Asset Type is created, open the Databricks application.
2. Navigate to the Asset Types tab.
3. Click Edit.
4. Select the relevant Asset Types you want to associate with the Databricks application.

Defining a Ruleset for Row-level Filtering

To define a Ruleset:
In the Asset type within the Ruleset tab, define the Row-level filtering logic using the Asset Attributes you created (for example, Status = 'Active').

You can use Databricks tables as an external Identity Source for contextual or dynamic rules (for example, Project_id = Assigned_project). See our article Managing Identity Source for more information.

Use PlainID's flexible logic to combine operators (=, !=, >, IN, etc.) with complex AND/OR relationships.

When Section

In the When section, you define the Conditions that provide contextual identity data for your Policy, which determine when the Policy applies.

To define a Condition:

1. Select an existing Condition or create a new one. A Policy can include multiple Conditions, combined with logical AND meaning all Conditions must be met for the Policy to grant access. Ensure that you select Conditions from Identity Attributes linked to the POP's Identity Source.
2. Click Save.

Conditions for Row-Level Requirements

• Only Conditions based on Identity Attributes are supported for use in Row Access Policies.
• Ensure that an Identity Source table is defined within your Policy Orchestration Point (POP).
• Use an Identity Attribute that is mapped to one of the additional Identity Sources associated with the selected POP.
• Within a single Condition, you can only use Attributes from one Source.

Deploying the Policy

Once complete, navigate to the Orchestration Workspace and deploy the Policy to Databricks.

Databricks enforces the access decision based on the Row-level filtering you've defined in the PlainID platform.

Databricks Row Filters - SQL Function Structure

Policy Syntax Table

Row Filter Example

CREATE OR REPLACE FUNCTION Row_function_project(Status STRING, project_id int)
RETURNS BOOLEAN
RETURN
CASE
  WHEN is_member('project_manager')
    AND status = 'Approved'
    AND EXISTS (
      SELECT 1
      FROM project_assignments
      WHERE current_user() = employee_name
        AND project_id = assigned_project_id
    )
  THEN TRUE
  ELSE FALSE
END;

ALTER TABLE `product_demo`.`schema1`.`projects`
SET ROW FILTER `product_demo`.`schema1`.`Row_function_project`
ON (`status`, `project_id`);