Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
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 Snowflake identifier requirements 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 configuration tutorial.
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 privilege grants.
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 migration guide.
To migrate from the private preview version of table grants (available before September 2022) to the GA version, complete the steps below.
Navigate to the App Settings page.
Click Integration Settings in the left panel, and scroll to the Global Integration Settings section.
Uncheck the Snowflake Table Grants checkbox to disable the feature.
Click Save. Wait for about 1 minute per 1000 users. This gives time for Immuta to drop all the previously created user roles.
Use the to re-enable the feature.
To or a Snowflake integration, you have two options:
Automatic: Grant Immuta one-time use of credentials to automatically edit or remove the integration.
The credentials provided must have the following permissions:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
Manual: Run the Immuta script in your Snowflake environment yourself to edit or remove the integration.
The specified role used to run the bootstrap needs to have the following privileges:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
Select one of the following options for editing your integration:
Click the App Settings icon in the left sidebar.
Click the Integrations tab and click the down arrow next to the Snowflake integration.
Edit the field you want to change or check a checkbox of a feature you would like to enable. Note any field shadowed is not editable, and the integration must be disabled and re-installed to change it.
From the Select Authentication Method Dropdown, select either Username and Password or Key Pair Authentication:
Username and Password option: Complete the Username, Password, and Role fields.
Key Pair Authentication option:
Complete the Username field.
When using a private key, enter the private key file password in the Additional Connection String Options. Use the following format: PRIV_KEY_FILE_PWD=<your_pw>
Click Key Pair (Required), and upload a Snowflake key pair file.
Complete the Role field.
Click Save.
Click the App Settings icon in the left sidebar.
Click the Integrations tab and click the down arrow next to the Snowflake integration.
Edit the field you want to change or check a checkbox of a feature you would like to enable. Note any field shadowed is not editable, and the integration must be disabled and re-installed to change it.
Download the Edit Script and run it in Snowflake.
Click Save.
Select one of the following options for deleting your integration:
Click the App Settings icon in the left sidebar.
Click the Integrations tab and click the down arrow next to the Snowflake integration.
Click the checkbox to disable the integration.
Enter the Username, Password, and Role that was entered when the integration was configured.
Click Validate Credentials.
Click Save.
Click the App Settings icon in the left sidebar.
Click the Integrations tab and click the down arrow next to the Snowflake integration.
Click the checkbox to disable the integration.
Download the Cleanup Script.
Click Save.
Run the cleanup script in Snowflake.
Deprecation notice
Support for this integration has been deprecated.
This page details how to install the for users on Snowflake Standard. If you currently use Snowflake Enterprise, see the .
Snowflake resource names
Use uppercase for the names of the Snowflake resources you create below.
Click the App Settings icon in the left sidebar.
Click the Integrations tab.
Click the +Add Native Integration button and select Snowflake from the dropdown menu.
Scroll down and uncheck the box for Snowflake Governance Features.
Scroll back up and complete the Host, Port, and Default Warehouse fields.
Opt to check the Enable Project Workspace box. This will allow for managed Write access within Snowflake.
Opt to check the Enable Impersonation box and customize the Impersonation Role name as needed. This will allow users to natively impersonate another user. Note you cannot edit this choice after you configure the integration.
is enabled by default; you can disable it by clicking the Enable Native Query Audit checkbox.
Configure the by scrolling to Integrations Settings and find the Snowflake Audit Sync Schedule section.
Enter how often, in hours, you want Immuta to ingest audit events from Snowflake as an integer between 1 and 24.
Continue with your integration configuration.
Opt to check the Automatically ingest Snowflake object tags box. This will enable Immuta to automatically import table and column tags from Snowflake. Note this feature requires an Enterprise Edition of Snowflake.
You have two options for installing the Snowflake and Snowflake Workspace access patterns: automatic or manual setup.
Known issue
To configure your Snowflake integration using password-only authentication in the automatic setup option, upgrade to Immuta v2024.2.7 or newer. Otherwise, Immuta will return an error.
Immuta requires temporary, one-time use of credentials with specific permissions.
When performing an automated installation, Immuta requires temporary, one-time use of credentials with the following permissions:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT
These permissions will be used to create and configure a new IMMUTA database within the specified Snowflake instance. The credentials are not stored or saved by Immuta, and Immuta doesn’t retain access to them after initial setup is complete.
You can create a new account for Immuta to use that has these permissions, or you can grant temporary use of a pre-existing account. By default, the pre-existing account with appropriate permissions is ACCOUNTADMIN. If you create a new account, it can be deleted after initial setup is complete.
Alternatively, you can create the IMMUTA database within the specified Snowflake instance manually using the Manual Setup option.
From the Select Authentication Method Dropdown, select either Username and Password or Key Pair Authentication:
Username and Password: Fill out the Username, Password, and Role fields.
Key Pair Authentication:
Complete the Username field.
When using a private key, enter the private key file password in the Additional Connection String Options. Use the following format: PRIV_KEY_FILE_PWD=<your_pw>
Click Key Pair (Required), and upload a Snowflake key pair file.
Complete the Role field.
Best Practices: Account Creation
The account you create for Immuta should only be used for the integration and should NOT be used as the credentials when creating data sources within Immuta. This will cause issues.
Create a dedicated READ-ONLY account for creating and registering data sources within Immuta. This account should also not be the account used to configure the integration.
The specified role used to run the bootstrap needs to have the following privileges:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT
Warning: Different Accounts
Download and run the bootstrap script linked in the Setup section. Take note of the username and password used in the script.
Use the Dropdown Menu to select your Authentication Method:
Username and Password: Enter the Username and Password that were that were set in the bootstrap script for the Immuta System Account Credentials.
Key Pair Authentication: Upload the Key Pair file and when using a private key, enter the private key file password in the Additional Connection String Options. Use the following format: PRIV_KEY_FILE_PWD=<your_pw>
If you enabled a Snowflake workspace, select Warehouses from the dropdown menu that will be available to project owners when creating native Snowflake workspaces. Select from a list of all the warehouses available to the privileged account entered above. Note that any warehouse accessible by the PUBLIC role does not need to be explicitly added.
Click Test Snowflake Connection.
Once the credentials are successfully tested, click Save.
Now that Snowflake has been enabled, all future Snowflake data sources will also be created natively within the immuta
database of the linked Snowflake instance. In addition to creating views, Immuta will also periodically sync user metadata to a system table within the Snowflake instance.
: Grant Immuta one-time use of credentials to automatically edit the integration.
: Run the Immuta script in your Snowflake environment yourself to edit the integration.
: Grant Immuta one-time use of credentials to automatically remove the integration and Immuta-managed resources from your Snowflake environment.
: Run the Immuta script in your Snowflake environment yourself to remove Immuta-managed resources and policies from Snowflake.
On September 30, 2024, Snowflake released a change to transition away from allowing password-only authentication. To use username and password authentication when configuring a new Snowflake integration, you must use the , which provides a script that permits password-only authentication by differentiating it as a legacy service with an additional parameter. Existing integrations will continue to function as-is.
The account used to enable the integration must be different from the account used to create data sources in Immuta. Otherwise, views won't be generated properly.
.
Migration troubleshooting
If multiple Snowflake integrations are enabled, they will all migrate together. If one fails, they will all revert to the Snowflake Standard integration.
If an error occurs during migration and the integration cannot be reverted, the integration must be disabled and re-enabled.
Click the App Settings icon in the left sidebar.
Click Preview Features in the left panel.
Scroll to the Native Snowflake Governance Controls modal and check the checkbox.
Using the credentials entered to enable the Snowflake integration, fill out the Username and Password or Key Pair.
Click Save.
Click Confirm.
This page details how to install the Snowflake integration for users on Snowflake Enterprise. If you currently use Snowflake Standard, see the installation guide for that integration.
Snowflake resource names
Use uppercase for the names of the Snowflake resources you create below.
Click the Integrations tab on the app settings page.
Click the +Add Native Integration button and select Snowflake from the dropdown menu.
Complete the Host, Port, and Default Warehouse fields.
Opt to check the Enable Project Workspace box. This will allow for managed write access within Snowflake. Note: Project workspaces still use Snowflake views, so the default role of the account used to create the data sources in the project must be added to the Excepted Roles List. This option is unavailable when table grants is enabled.
Opt to check the Enable Impersonation box and customize the Impersonation Role to allow users to natively impersonate another user. You cannot edit this choice after you configure the integration.
Snowflake query audit is enabled by default; you can disable it by clicking the Enable Native Query Audit checkbox.
Configure the audit frequency by scrolling to Integrations Settings and find the Snowflake Audit Sync Schedule section.
Enter how often, in hours, you want Immuta to ingest audit events from Snowflake as an integer between 1 and 24.
Continue with your integration configuration.
Opt to check the Automatically ingest Snowflake object tags box to allow Immuta to automatically import table and column tags from Snowflake.
Altering parameters in Snowflake at the account level may cause unexpected behavior of the Snowflake integration in Immuta
The QUOTED_IDENTIFIERS_IGNORE_CASE
parameter must be set to false
(the default setting in Snowflake) at the account level. Changing this value to true
causes unexpected behavior of the Snowflake integration.
You have two options for configuring your Snowflake environment:
Automatic setup: Grant Immuta one-time use of credentials to automatically configure your Snowflake environment and the integration.
Manual setup: Run the Immuta script in your Snowflake environment yourself to configure your Snowflake environment and the integration.
Known issue
On September 30, 2024, Snowflake released a change to transition away from allowing password-only authentication. To use username and password authentication when configuring a new Snowflake integration, you must use the manual setup option, which provides a script that permits password-only authentication by differentiating it as a legacy service with an additional parameter. Existing integrations will continue to function as-is.
To configure your Snowflake integration using password-only authentication in the automatic setup option, upgrade to Immuta v2024.2.7 or newer. Otherwise, Immuta will return an error.
Immuta requires temporary, one-time use of credentials with specific permissions.
When performing an automated installation, Immuta requires temporary, one-time use of credentials with the following permissions:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
These permissions will be used to create and configure a new IMMUTA database within the specified Snowflake instance. The credentials are not stored or saved by Immuta, and Immuta doesn’t retain access to them after initial setup is complete.
You can create a new account for Immuta to use that has these permissions, or you can grant temporary use of a pre-existing account. By default, the pre-existing account with appropriate permissions is ACCOUNTADMIN. If you create a new account, it can be deleted after initial setup is complete.
Alternatively, you can create the IMMUTA database within the specified Snowflake instance manually using the manual setup option.
From the Select Authentication Method Dropdown, select one of the following authentication methods:
Username and Password: Complete the Username, Password, and Role fields.
Key Pair Authentication:
Complete the Username field.
When using a private key, enter the private key file password in the Additional Connection String Options. Use the following format: PRIV_KEY_FILE_PWD=<your_pw>
Click Key Pair (Required), and upload a Snowflake key pair file.
Complete the Role field.
Best practices: account creation
The account you create for Immuta should only be used for the integration and should not be used as the credentials for creating data sources in Immuta; doing so will cause issues. Instead, create a separate, dedicated READ-ONLY account for creating and registering data sources within Immuta.
The specified role used to run the bootstrap needs to have the following privileges:
CREATE DATABASE ON ACCOUNT WITH GRANT OPTION
CREATE ROLE ON ACCOUNT WITH GRANT OPTION
CREATE USER ON ACCOUNT WITH GRANT OPTION
MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION
APPLY MASKING POLICY ON ACCOUNT WITH GRANT OPTION
APPLY ROW ACCESS POLICY ON ACCOUNT WITH GRANT OPTION
It will create a user called IMMUTA_SYSTEM_ACCOUNT
, and grant the following privileges to that user:
APPLY MASKING POLICY ON ACCOUNT
APPLY ROW ACCESS POLICY ON ACCOUNT
Additional grants associated with the IMMUTA database
If you have selected to automatically ingest Snowflake object tags, which enables Snowflake tag ingestion,
GRANT IMPORTED PRIVILEGES ON DATABASE snowflake
GRANT APPLY TAG ON ACCOUNT
Select Manual.
Use the Dropdown Menu to select your Authentication Method:
Username and password: Enter the Username and Password and set them in the bootstrap script for the Immuta system account credentials.
Key pair authentication: Upload the Key Pair file and when using a private key, enter the private key file password in the Additional Connection String Options. Use the following format: PRIV_KEY_FILE_PWD=<your_pw>
Snowflake External OAuth:
Create a security integration for your Snowflake External OAuth. Note that if you have an existing security integration, then the Immuta system role must be added to the existing EXTERNAL_OAUTH_ALLOWED_ROLES_LIST
. The Immuta system role will be the Immuta database provided above with _SYSTEM
. If you used the default database name it will be IMMUTA_SYSTEM
.
Fill out the Token Endpoint. This is where the generated token is sent and is also known as aud
(Audience) and iss
(Issuer).
Fill out the Client ID. This is the subject of the generated token and is also known as sub
(Subject).
Select the method Immuta will use to obtain an access token:
Certificate:
Keep the Use Certificate checkbox enabled.
Opt to fill out the Resource field with a URI of the resource where the requested token will be used.
Enter the x509 Certificate Thumbprint. This identifies the corresponding key to the token and is often abbreviated as x5t
or is called sub
(Subject).
Upload the PEM Certificate, which is the client certificate that is used to sign the authorization request.
Client secret:
Uncheck the Use Certificate checkbox.
Enter the Scope (string). The scope limits the operations and roles allowed in Snowflake by the access token. See the Microsoft OAuth 2.0 client credentials flow documentation for details about scopes.
Enter the Client Secret (string). Immuta uses this secret to authenticate with the authorization server when it requests a token.
Download, fill out the appropriate fields, and run the bootstrap script linked in the Setup section.
Warning: different accounts
The account used to enable the integration must be different from the account used to create data sources in Immuta. Otherwise, workspace views won't be generated properly.
If you enabled a Snowflake workspace, select Warehouses from the dropdown menu that will be available to project owners when creating native Snowflake workspaces. Select from a list of all the warehouses available to the privileged account entered above. Note that any warehouse accessible by the PUBLIC role does not need to be explicitly added.
Enter the Excepted Roles/User List. Each role or username (both case-sensitive) in this list should be separated by a comma.
Excepted roles/users will have no policies applied to queries.
Any user with the username or acting under the role in this list will have no policies applied to them when querying Immuta protected Snowflake tables in Snowflake. Therefore, this list should be used for service or system accounts and the default role of the account used to create the data sources in the Immuta projects (if you have Snowflake workspace enabled).
Click Test Snowflake Connection.
Once the credentials are successfully tested, click Save and Confirm your changes.
If you have Snowflake low row access policy mode enabled in private preview and have impersonation enabled, see these . 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 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.
Click Save and Confirm your changes.
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 .
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.
Immuta is compatible with . 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 and .
Prerequisites:
Required Permission: Immuta: GOVERNANCE
to fit your organization's compliance requirements.
Required Permission: Immuta: USER_ADMIN
To register the Snowflake data consumer in Immuta,
.
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.
for your organization's policies.
.
Required Permission: Snowflake: ACCOUNTADMIN
To share the policy-protected data source,
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
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
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
Required Permission: Snowflake: ACCOUNTADMIN
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
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:
If you already have a 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.
. Note that you will not be able to enable project workspaces or user impersonation with Snowflake low row access policy mode enabled.
of the Snowflake table that has been registered in Immuta.
Using an model, to fit your organization's compliance requirements.
with the data sources that you will be sharing, a Snowflake workspace, and .
A user with the same attributes or groups as the data consumer must to represent the appropriate attributes and groups of the data consumer.
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.
.