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:

• Snowflake Integration Using Snowflake Governance Features
• Snowflake Integration Without Snowflake Governance Features

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

You can migrate from a Snowflake integration without governance features to a Snowflake integration with 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 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.

Supported Features

The Immuta Snowflake integration supports the following features:

• Snowflake Table Grants (Public 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.
• Snowflake External Tables. However, you cannot add a masking policy to an external table column while creating the external table in Snowflake because masking policies cannot be attached to virtual columns.

Authentication Methods

The Snowflake integration supports the following authentication methods to install the integration and create data sources:

• Username and Password: Users can authenticate with their Snowflake username and password.
• Key Pair: Users can authenticate with a Snowflake Key Pair Authentication.
• Snowflake External OAuth: Users can authenticate with Snowflake External OAuth when using Snowflake with governance features.

Snowflake External OAuth

Immuta's OAuth authentication method uses Client Credentials Flow to integrate with Snowflake External OAuth. When a user configures the Snowflake integration or connects a Snowflake data source, Immuta uses the token credentials to craft an authenticated access token to connect with Snowflake. This allows organizations that already use Snowflake External OAuth to use that secure authentication with Immuta.

Workflow

1. An Immuta Application Administrator configures the Snowflake integration or creates a data source.
2. Immuta creates a custom token and sends it to the Authorization Server.
3. The Authorization Server confirms the information sent from Immuta and issues an access token to Immuta.
4. Immuta sends the access token it received from the Authorization Server to Snowflake.
5. Snowflake authenticates the token and grants access to the requested resources from Immuta.
6. The integration is connected and users can query data.

Workspaces

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 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

When configuring a 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:

• Manually Enable Snowflake Tag Ingestion: This tutorial is intended for users who want Snowflake tags to be ingested into Immuta but do not want users to query data sources natively in Snowflake.
• Automatically Enable Snowflake Tag Ingestion: This tutorial illustrates how to enable Snowflake tag ingestion when configuring a Snowflake integration.

Caveats

Snowflake has some natural data latency. If you manually refresh the Governance page to see all globally created tags, users can experience a delay of up to two hours. However, if you run schema detection or a health check to find where those tags are applied, the delay will not occur because Immuta will only search for tags on those specific tables.

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.

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 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 integration connection per host.
• The host of the data source must match the host of the integration connection for the 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 with 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.

• You cannot add a masking policy to an external table column while creating the external table because a masking policy cannot be attached to a virtual column.

• If you create an Immuta data source from a Snowflake view created using a select * from query, Immuta column detection will not work as expected because Snowflake views are not automatically updated based on backing table changes. To remedy this, you can create views that have the specific columns you want or you can CREATE AND REPLACE the view in Snowflake whenever the backing table is updated and manually run the column detection job on the data source page.

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
   • Understanding Column-level Security
   • Understanding Row Access Policies

Snowflake Integration Without Snowflake Governance Features Limitations

• Certain interpolation functions can also block the creation of a 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.