Loading...
Loading...
Loading...
Loading...
Loading...
If you have Snowflake low row access policy mode enabled in private preview and have impersonation enabled, see these upgrade instructions. Otherwise, query performance will be negatively affected.
Snowflake low row access policy mode is enabled by default. However, you can disable or re-enable the feature by following the steps below.
Click the App Settings icon in the sidebar and scroll to the Global Integration Settings section.
Click the Enable Snowflake Low Row Access Policy Mode checkbox to disable the feature.
Click Save and confirm your configuration changes.
If you already have a Snowflake governance features integration configured, you don't need to reconfigure your integration. Your Snowflake policies automatically refresh when you enable or disable Snowflake low row access policy mode.
Click Save and Confirm your changes.
Click the App Settings icon in the sidebar and scroll to the Global Integration Settings section.
Click the Enable Snowflake Low Row Access Policy Mode checkbox to re-enable the feature.
Confirm to allow Immuta to automatically disable impersonation for the Snowflake integration. If you do not confirm, you will not be able to enable Snowflake low row access policy mode.
Click Save and confirm your configuration changes.
If you already have a Snowflake governance features integration configured, you don't need to reconfigure your integration. Your Snowflake policies automatically refresh when you enable or disable Snowflake low row access policy mode.
Configure your Snowflake integration with governance features enabled. Note that you will not be able to enable project workspaces or user impersonation with Snowflake low row access policy mode enabled.
Click Save and Confirm your changes.
Navigate to the App Settings page.
Scroll to the Global Integration Settings section.
Ensure the Snowflake Governance Features checkbox is checked. It is enabled by default.
Ensure the Snowflake Table Grants checkbox is checked. It is enabled by default.
Opt to change the Role Prefix. Snowflake table grants creates a new Snowflake role for each Immuta user. To ensure these Snowflake role names do not collide with existing Snowflake roles, each Snowflake role created for Snowflake table grants requires a common prefix. When using multiple Immuta accounts within a single Snowflake account, the Snowflake table grants role prefix should be unique for each Immuta account. The prefix must adhere to and be less than 50 characters. Once the configuration is saved, the prefix cannot be modified; however, the Snowflake table grants feature can be disabled and re-enabled to change the prefix.
Finish configuring your integration by following one of these guidelines:
New Snowflake integration: Set up a new Snowflake integration by following the .
Existing Snowflake integration (automatic setup): You will be prompted to enter connection information for a Snowflake user. Immuta will execute the migration to Snowflake table grants using a connection established with this Snowflake user. The Snowflake user you provide here must have Snowflake privileges to run these .
Existing Snowflake integration (manual setup): Immuta will display a link to a migration script you must run in Snowflake and a link to a rollback script for use in the event of a failed migration. Important: Execute the migration script in Snowflake before clicking Save on the app settings page.
Snowflake table grants private preview migration
To migrate from the private preview version of Snowflake table grants (available before September 2022) to the generally available version of Snowflake table grants, follow the steps in the .
Immuta is compatible with Snowflake Secure Data Sharing. Using both Immuta and Snowflake, organizations can share the policy-protected data of their Snowflake database with other Snowflake accounts with Immuta policies enforced in real time. See below for instructions on using Snowflake Data Sharing with Immuta Users using Immuta's table grants feature and Snowflake Data Sharing with non-Immuta users using Immuta's project workspaces.
Prerequisites:
Required Permission: Immuta: GOVERNANCE
Build Immuta data policies to fit your organization's compliance requirements.
Required Permission: Immuta: USER_ADMIN
To register the Snowflake data consumer in Immuta,
Update the Immuta user's Snowflake username to match the account ID for the data consumer. This value is the output on the data consumer side when SELECT CURRENT_ACCOUNT() is run in Snowflake.
Give the Immuta user the appropriate attributes and groups for your organization's policies.
Required Permission: Snowflake: ACCOUNTADMIN
To share the policy-protected data source,
Create a Snowflake Data Share of the Snowflake table that has been registered in Immuta.
Grant reference usage on the Immuta database to the share you created:
Replace the content in angle brackets above with the name of your Immuta database and Snowflake data share.
Prerequisites:
Use Case
As you follow this tutorial, these callouts will have examples centered around the same use case and will further explain the steps necessary to meet the following compliance requirement:
Compliance Requirement: Users can only see data from their country.
Use Case: Create Policies
The Immuta user will create a global data policy that restricts the rows users can see based on their attributes, which identify their country. In the example below, users with the attribute Country.JP would only see rows that have JP as a value in the CREDIT POINT OF SALE column.
Required Permission: Immuta: GOVERNANCE
Using an attribute based access control (ABAC) model, build Immuta data policies using Immuta attributes and groups to fit your organization's compliance requirements.
Use Case: Create Project
The Immuta user will create a project for the data share. In the example below, the user creates a Japan Data Share project that will only be shared with data consumers in Japan.
Required Permission: Immuta: CREATE_PROJECT
Create an Immuta project with the data sources that you will be sharing, a Snowflake workspace, and project equalization enabled.
Use Case
Because data consumers have the attribute "Country.JP", this will be the equalized entitlement added to the project. The Immuta user editing the equalized entitlement must also have the attribute "Country.JP" to ensure they have access to the data they will share.
Required Permission: Immuta: CREATE_PROJECT or PROJECT_MANAGEMENT
A user with the same attributes or groups as the data consumer must edit the equalized entitlements to represent the appropriate attributes and groups of the data consumer.
Required Permission: Snowflake: ACCOUNTADMIN
Create the Snowflake Data Share pointing to the project workspace using the schema and role in the Native Snowflake Access section of the project information. Repeat this step for each data source you want to share.
The commands run in Snowflake should look similar to this:
Private preview
This feature is only available to select accounts. Reach out to your Immuta representative to enable this feature.
Snowflake Enterprise Edition
Contact your Immuta representative to enable this feature in your Immuta tenant.
Navigate to the App Setting page and click the Integration tab.
Click +Add Native Integration and select Snowflake from the dropdown menu.
Complete the Host, Port, and Default Warehouse fields.
Enable Native Query Audit.
Enable Native Lineage and complete the following fields:
Ingest Batch Sizes: This setting configures the number of rows Immuta ingests per batch when streaming Access History data from your Snowflake instance.
Table Filter: This filter determines which tables Immuta will ingest lineage for. Enter a regular expression that excludes / from the beginning and end to filter tables. Without this filter, Immuta will attempt to ingest lineage for every table on your Snowflake instance.
Tag Filter: This filter determines which tags to propagate using lineage. Enter a regular expression that excludes / from the beginning and end to filter tags. Without this filter, Immuta will ingest lineage for every tag on your Snowflake instance.
Opt to enable Automatically ingest Snowflake object tags.
Select Manual or Automatic Setup and follow the steps in this guide to configure the Snowflake integration
Authenticate with the Immuta API.
The Snowflake lineage sync endpoint triggers the native lineage ingestion job that allows Immuta to propagate Snowflake tags added through lineage to Immuta data sources.
Copy the example and replace the Immuta URL and API key with your own.
Change the payload attribute values to your own, where
tableFilter (string): This regular expression determines which tables Immuta will ingest lineage for. Enter a regular expression that excludes / from the beginning and end to filter tables. Without this filter, Immuta will attempt to ingest lineage for every table on your Snowflake instance.
batchSize (integer): This parameter configures the number of rows Immuta ingests per batch when streaming Access History data from your Snowflake instance. Minimum 1.
lastTimestamp (string): Setting this parameter will only return lineage events later than the value provided. Use a format like 2022-06-29T09:47:06.012-07:00.
Once the sync job is complete, you can complete the following steps:
The steps outlined on this page are necessary if you meet both of the following criteria:
You have the Snowflake low row access policy mode enabled in private preview.
You have user impersonation enabled.
If you do not meet this criteria, follow the instructions on the configuration guide.
To upgrade to generally available version of the feature, either
disable your Snowflake integration on the app settings page and then re-enable it, OR
disable Snowflake low row access policy mode on the app settings page and re-enable it.