Row-Level Security

Row-level security (RLS) is a fine-grained access control mechanism that restricts which rows of data a user can access within a table. This is implemented using the Row Access Policy.
This is a schema-level object that secures Snowflake database objects (e.g. Tables or Views) and determines which rows should be visible to users based on their role or other dynamic context.

It enables fine-grained access control by dynamically filtering data at query time, using conditional expressions and context functions (such as CURRENT_ROLE(), SESSION_USER(), or other Snowflake identity functions).

Creating a 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. Input the Policy Details. For more information, refer to the Creating Policies article

2. Input the Snowflake POP Details specific to the vendor Policy:

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

   • Enter a Vendor Policy Name, a unique name for the Policy that will appear in the Snowflake vendor. (Required)
     Note: The same name can be used across multiple PlainID Policies to define multiple logic statements within a single Snowflake Row Access Policy.

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

   • Define the Vendor Policy Order, which relates to the execution order for the logical case statement within the same Vendor Policy ID. (Required)

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

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

   • Under Database, select the Snowflake database where the Policy will be deployed.

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

   • Input an Owner, provide the POP Snowflake role used to manage the Policy.

3. Click Continue.

Who Section

In the Who section, you assign Row-level access by creating a new Dynamic Group or selecting an existing one. A single Policy can evaluate multiple Dynamic Groups, giving you flexibility in defining access control logic.

Dynamic Groups are defined using Snowflake identity functions such as CURRENT_USER(), CURRENT_ROLE(), IS_ROLE_IN_SESSION(), and CURRENT_SECONDARY_ROLES(). You can use multiple identity functions within the same group to refine access.

For information on how to create a Dynamic Group, see Managing Dynamic Groups.

What Section

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

For more details on Asset Types, refer to Managing Asset Types.

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, note all combined with logical OR.

See Defining a Ruleset for Row-evel 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. Follow the above instructions to edit or create an Asset Type.
  2. Ensure that "Is used for data filtering?" is enabled.
  3. Select Set Table Mapping to link your logical Asset Type with one or more physical Tables or Views in Snowflake where the Row Access Policy should apply.

  The mapping must include the fully qualified path to the table or view, following the format: DB_NAME.SCHEMA_NAME.TABLE_NAME.

For more information about Table Mapping, refer to Dynamic Data Mapping.

• Attribute Mapping
  To set Attribute Mapping:
  1. Choose an existing Attribute or create a new one to use in your filtering logic.
     Refer to Managing Asset Attributes for more details.
  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 Snowflake column/s.

To connect an Asset Type with the Snowflake Application:

1. Once the Asset Type is created, open the Snowflake application.
2. Navigate to the Asset Types tab.
3. Click Edit.
4. Select the relevant Asset Types you want to associate with the Snowflake 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, Access_Type = 'support' AND Tier = 'Gold').
• You can use Snowflake tables as an external Identity Source for contextual or dynamic rules (for example, Department = user.department). See our Managing Identity Source article 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. 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. However, note that only one Identity Attribute Condition is supported. Ensure that you select Conditions from Identity Attributes linked to the POP’s Identity Source.
   • See Managing Conditions to learn how to create a new one Identity Attribute Condition.
   • Ensure that the Condition meets the Conditions for Row-Level Requirements.
2. Click Save.

Conditions for Row-Level Requirements

• 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. For more details, refer to our Managing Identity Source article.
  • 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 Snowflake.
Snowflake enforces the access decision based on the Row-level filtering you've defined in the PlainID platform.

Snowflake Row Access Policy SQL Structure

This table describes the Snowflake Row Access Policy components in SQL and compares them to their equivalents in PlainID to help you translate and build your policies easily within the PlainID Platform.

Policy Syntax Table

Row Access Policy Example

This example grants support_engineer access only to rows where Access_Type = 'support' and Tier = 'Gold' using a Row Access Policy.

CREATE OR REPLACE ROW ACCESS POLICY support_engineer_access_policy
AS (Access_Type VARCHAR, Tier VARCHAR) RETURNS BOOLEAN ->
CASE
  WHEN CURRENT_ROLE() = 'support_engineer'
  AND Access_Type = 'support' AND Tier= 'Gold'
  THEN TRUE
  ELSE FALSE
END;

ALTER TABLE sales_table ADD ROW ACCESS POLICY support_engineer_access_policy
ON (Access_Type,Tier);

For the current role, support_manager, the Policy allows access only to rows where Ticket_ID=T001 and T004.