Skip to content

Snowflake Pre-Configuration Details

Audience: System Administrators, Data Owners, and Data Users

Content Summary: This page describes Immuta's Snowflake integrations, their configuration options, and their features.

These options are available with both integrations unless otherwise indicated:

See the Snowflake integration page for a tutorial on enabling Snowflake and these features through the App Settings page.

Feature Availability

Project Workspaces Snowflake Tag Ingestion User Impersonation Native Query Audit Multiple Integrations
✅ ✅ ✅ ✅ ✅

Snowflake-Specific Details

Integration Migration

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.

You can migrate from a Snowflake integration without Snowflake Governance Features to a Snowflake integration with Snowflake Governance Features on the App Settings page. Once prompted, Immuta will migrate the integration, allowing users to seamlessly transition workloads from the legacy Immuta views to the direct Snowflake tables.

After the migration is complete, Immuta views will still exist for pre-existing Snowflake data sources to support existing workflows. However, disabling the Immuta data source will drop the Immuta view, and, if the data source is re-enabled, the view will not be recreated.

You can migrate back to a Snowflake integration without Snowflake Governance Features from the Snowflake integration using Governance Features if any issues occur. However, this process is only intended to resolve any issues that occur during migration and regain utility of Immuta. Please consult your Immuta professional for assistance.

Access must be revoked.

Access to the Snowflake tables must be revoked when migrating back from the Snowflake Integration using Governance Features to the not using Governance Features to prevent users from having access to the raw tables.

Supported Features

The Immuta Snowflake integration supports the following features:

  • Snowflake Table Grants (Private Preview): This feature allows Immuta to manage privileges on your Snowflake tables and views according to the subscription policies on the corresponding Immuta data sources.

Workspaces

Immuta System Account Required Snowflake Privileges
  • CREATE [OR REPLEACE] PROCEDURE
  • DROP ROLE
  • REVOKE ROLE

Users can have additional write access in their integration using project workspaces. For more details, see the Snowflake Project Workspaces page.

Caveat

  • To use project workspaces with the Snowflake integration with Snowflake Governance Features, the default role of the account used to create data sources in the project must be added to the "Excepted Roles/Users List." If the role is not added, you will not be able to query the equalized view using the project role in Snowflake.

Tag Ingestion

Immuta System Account Required Snowflake Privileges
  • GRANT IMPORTED PRIVILEGES ON DATABASE snowflake
  • GRANT APPLY TAG ON ACCOUNT

When configuring a native Snowflake integration, you can enable Snowflake tag ingestion as well. With this feature enabled, Immuta will automatically ingest Snowflake object tags from your Snowflake instance into Immuta and add them to the appropriate data sources.

The Snowflake tags' Key and Value pairs will be reflected in Immuta as two levels: the Key will be the top level and the Value the second. As Snowflake tags are hierarchical, Snowflake tags applied to a database will also be applied to all of the schemas in that database, all of the tables within those schemas, and all of the columns within those tables. For example: If a database is tagged PII, all of the tables and columns in that database will also be tagged PII.

To enable Snowflake tag ingestion, follow one of the tutorials below:

Caveats

Snowflake has some natural data latency. Even when manually refreshing external tags from the Governance page, users can experience a delay of up to two hours in updated tags. This delay can be avoided by manually refreshing tags through a data source's Health Check.

User Impersonation

Native impersonation allows users to natively query data as another Immuta user. To enable native user impersonation, see the Integration User Impersonation page.

Native Query Audit

Prerequisite: This feature requires Snowflake Enterprise Edition.

Immuta System Account Required Snowflake Privileges
  • IMPORTED PRIVILEGES ON DATABASE snowflake

Once this feature has been enabled on the App Settings page with the Snowflake integration, Immuta will run a query against Snowflake to retrieve the query histories. These histories provide audit records for queries against Snowflake native data sources that are queried natively in Snowflake.

This process will happen automatically every 24 hours, or can be manually prompted at any time from the Immuta Audit page. When manually prompted, it will only search for new queries that were created since the latest native query that has been audited. The job is run in the background, so the new queries will not be immediately available.

For details about prompting these logs and the contents of these audits, see the Snowflake Native Query Audit Logs page.

Caveats

  • The scheduled and manual jobs that query Snowflake are run in the background. The audit records will not update immediately.
  • If you are relying on the scheduled job, any audit records for queries run in the day will not appear until the next day, at the earliest. In some cases, they could appear another day later.
  • This feature is only available with Snowflake Enterprise or higher.

Multiple Snowflake Instances

A user can configure multiple integrations of Snowflake to a single Immuta instance and use them dynamically or with workspaces.

Caveats

  • There can only be one native connection per host.
  • The host of the data source must match the host of the native connection for the native view to be created.
  • Projects can only be configured to use one Snowflake host.

Snowflake Integration Using Snowflake Governance Features Limitations

  • Immuta policies that rely on a masked column as input cannot be natively queried in Snowflake. These policies will present a message upon creation and in the health status of any affected data sources. To avoid any data leaks, more strict masking will be enforce until the policies are changed.

    • Additionally, if there is any other error in generating or applying policies natively in Snowflake, the data source will be locked and only users on the Excepted Roles/Users List and the credentials used to create the data source will be able to access the data.
  • Users are unable to rollback from the Snowflake Integration using Governance Features to the not using Governance Features if Snowflake SQL-backed data sources exist. Before trying to rollback, edit the data sources to be Snowflake tables or views.

  • Once a Snowflake integration is disabled in Immuta, the user must remove the access that was granted in Snowflake. If that access is not revoked, users will be able to access the raw table in Snowflake.

  • Migration must be done using the credentials and credential method (automatic or bootstrap) used to install the integration.

  • When configuring one Snowflake instance with multiple Immuta instances, the user or system account that enables the integration on the App Settings page must be unique for each Immuta instance.

  • A Snowflake table can only have one set of policies enforced at a given time, so creating multiple data sources pointing to the same table is not supported. If this is a use case you need to support, create views in Snowflake and expose those instead.

Custom WHERE Clause Limitations

The Immuta Snowflake integration uses Snowflake Governance features to let users query data natively in Snowflake. This means that Immuta also inherits some Snowflake limitations using correlated subqueries with Row Access Policies and Column-level Security. These limitations appear when writing custom WHERE policies, but do not remove the utility of row-level policies.

Requirements for a Custom WHERE Policy

  1. All column names must be fully qualified:

    1. Any column names that are unqualified (i.e., just the column name) will default to a column of the data source the policy is being applied to (if one matches the name).
  2. The Immuta system account must have SELECT privileges on all tables/views referenced in a subquery:

    1. The Immuta system role name is specified by the user, and the role is created when the Snowflake instance is integrated.

Subquery Limitations

Any subqueries that error in Snowflake will also error in Immuta.

  1. Including one or more subqueries in the Immuta policy condition may cause errors in Snowflake. If an error occurs, it may happen during policy creation or at query-time. To avoid these errors, limit the number of subqueries, limit the number of JOIN operations, and simplify WHERE clause conditions.
  2. For more information on the Snowflake subquery limitations see

Snowflake Integration Without Snowflake Governance Features Limitations

  • Certain interpolation functions can also block the creation of a native view, specifically @interpolatedComparison() and @iam.

  • When configuring one Snowflake instance with multiple Immuta instances, the user or system account that enables the integration on the App Settings page must be unique for each Immuta instance.