Snowflake Integration Reference Guide

Learn about how the Snowflake integration works and what Immuta creates in your environment to administer Snowflake access controls directly on objects in Snowflake

New connections

The new connections flow documented here is available and released to select tenants.

Using the Snowflake connection, you can register a Snowflake integration for your Snowflake Enterprise account.

The sequence diagram below outlines the events that occur when an Immuta user wants to query a Snowflake table that has been registered as an Immuta data source.

What does Immuta do in my environment?

Registering a connection

Immuta utilizes connections to register and manage data from your entire Snowflake environment all at once. This approach simplifies data registration and allows Immuta to automatically monitor your Snowflake platform for changes. Data sources are then added or removed to reflect the current state of your data platform.

When a connection is first registered, Immuta will ask your application admin to provide the following:

The name of an Immuta system database in Snowflake that Immuta will control and create schemas (immuta_procedures, immuta_policies, and immuta_functions) in to contain policy definitions and user entitlements. This database will be created when you run the setup script.
A Snowflake role with the required privileges that the system account will use to maintain state of data objects between Snowflake and Immuta.
A set of Snowflake credentials to a system account with the required privileges to connect between Snowflake and Immuta. These credentials will be used to initially register all your Snowflake objects as data objects. Immuta will also continue to use those credentials for scheduled object syncs, identification, and to orchestrate policies in Snowflake.

The application admin will then run the setup script in Snowflake, which will create the following:

The new Immuta system database to contain policy definitions and user entitlements.
A new system Snowflake role to orchestrate policies in Snowflake, which will be attached to the Snowflake system account.

When policies are applied to Snowflake objects, the following will be done in your Snowflake environment:

Subscription policies will require a new role to be created for each user, which will be granted access to the object in Snowflake. The role prefix is set on the Immuta app settings page. For example, if the user is jane.doe@immuta.com and if the role prefix is set to IMMUTA, the role will be IMMUTA_USER_jane.doe@immuta.com and granted access to the table.
Data policies will require Immuta to manage and apply Snowflake governance column and row access policies to Snowflake objects that are registered as Immuta data sources using the system Snowflake account and role.

After the setup and registration is complete, Immuta ingests and stores connection metadata in the Immuta metadata database. In the example below, the Immuta application administrator connects the database that contains marketing-data, research-data, and cs-data tables. Immuta registers these tables as data objects and stores the table metadata in the Immuta metadata database. Creating the connection does not impact any user's existing access in Snowflake until subscription policies are applied to the tables.

Beyond making the registration of your data more intuitive, connections provide more control. Instead of performing operations on individual schemas or tables, you can perform operations (such as object sync) at the connection level.

See the Connections reference guide for details about connections and how to manage them. To configure your Snowflake connection, see the Register a Snowflake connection guide.

Applying policies

By default, the Snowflake integration is designed to be minimally invasive: if a table does not have policy sync enabled, users will still have access to it in Snowflake.

Subscription policies

Immuta enforces read and write subscription policies on Snowflake tables by granting access to the appropriate tables in Snowflake.

Once the connection is registered, this is what happens when a user applies a subscription policy to a Snowflake data source:

Immuta creates a role for the user querying the table in Snowflake, if one doesn't already exist. The role will be <IMMUTA>_USER_<username>.
Snowflake stores that role in its internal system catalog.
Immuta issues grants to that user's role in Snowflake to enforce policy. The Protecting data page provides an example of this policy enforcement.
Immuta will then grant that personalized role to the Immuta user in Snowflake. The Accessing data page provides details about how the user should set their Snowflake roles.
Users will query data in Snowflake, using USE SECONDARY ROLES ALL, which allows them to use the privileges from all roles that have been granted to them including the <IMMUTA>_USER_<username> role and their current active primary role.

Data policies

You can author data policies in Immuta to enforce fine-grained access controls on Snowflake data objects registered as Immuta data sources. For more details about how enforcement works, see the Protecting data page.

When a data policy is applied to a Snowflake data source in Immuta,

A data owner, data governor, or administrator creates or changes a policy or a user's attributes change in Immuta.
Immuta manages and applies Snowflake governance column and row access policies to Snowflake tables that are registered as Immuta data sources using the system Snowflake account and role.
A Snowflake user who is subscribed to the data source in Immuta queries the corresponding table directly in Snowflake and sees policy-enforced data.

See the integration support matrix on the Data policy types reference guide for a list of supported data policy types in Snowflake.

Snowflake privileges granted by Immuta

See the Subscription policy access types page for details about the Snowflake privileges granted to users when they are subscribed to a data source protected by a subscription policy.

Required Snowflake privileges

The privileges the Snowflake integration requires align to the least privilege security principle. The table below describes each privilege required in Snowflake for the setup user or the system account user. The references to IMMUTA_DB , IMMUTA_WH, and IMMUTA_IMPERSONATOR_ROLE in the table can be replaced with what you chose for the name of your Immuta database, warehouse, and impersonation role when setting up the integration, respectively.

Snowflake privilege

User requiring privilege

Features

Explanation

CREATE DATABASE ON ACCOUNT WITH GRANT OPTION

Setup user

All

The setup script this user runs creates an Immuta database in your organization's Snowflake account where all Immuta managed objects (UDFs, masking policies, row access policies, and user entitlements) will be written and stored.

CREATE ROLE ON ACCOUNT WITH GRANT OPTION

Setup user

All

The setup user must create a ROLE for Immuta that will be used to manage the integration and policies once it has been initialized.

MANAGE GRANTS ON ACCOUNT

Setup user

All

The user registering the connection must be able to GRANT global privileges and access to objects within the Snowflake account. All privileges that are documented here must be granted to the system account user by the setup user manually or through the setup script.

ALL PRIVILEGES ON DATABASE IMMUTA_DB
ALL PRIVILEGES ON ALL SCHEMAS IN DATABASE IMMUTA_DB
USAGE ON FUTURE PROCEDURES IN SCHEMA IMMUTA_DB.IMMUTA_PROCEDURES

System account user

All

Immuta requires these privileges because Immuta must have full ownership of the Immuta database where Immuta objects are managed.

USAGE ON WAREHOUSE IMMUTA_WH

System account user

All

To make changes to state in the Immuta database, Immuta requires access to compute (a Snowflake warehouse). Some state changes are DDL operations, and others are DML and require compute.

IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE

System account user

Audit

To ingest audit information from Snowflake, Immuta must have access to the SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY view. See the Snowflake documentation for details.

APPLY MASKING POLICY ON ACCOUNT
APPLY ROW ACCESS POLICY ON ACCOUNT

System account user

Data policies

Immuta must be able to apply policies to objects throughout your organization's Snowflake account and query for existing policies on objects using the POLICY_REFERENCES table function.

SELECT on all tables and views registered in Immuta

System account user

Identification and specialized masking policies that require fingerprinting

Immuta must have this privilege to run the necessary queries for identification on your data sources.

OWNERSHIP ON ROLE IMMUTA_IMPERSONATOR_ROLE

System account user

Impersonation

If impersonation is enabled, Immuta must be able to manage the Snowflake roles used for impersonation in order to manage the impersonation feature.

USAGE on all databases and schemas with registered data sources
REFERENCES on all tables and views registered in Immuta

System account user

Object sync

Immuta must be able to see metadata on securables to register them as data sources.

MANAGE GRANTS ON ACCOUNT or OWNERSHIP on the objects that Immuta will secure

System account user

Subscription policies

Immuta must be able to MANAGE GRANTS on objects throughout your organization's Snowflake account.

CREATE ROLE ON ACCOUNT

System account user

Subscription policies

Immuta must be able to create roles as targets for Immuta subscription policy permissions in your organization’s Snowflake account.

APPLY TAG ON ACCOUNT

System account user

Tag ingestion

To ingest table, view, and column tag information from Snowflake, Immuta must have this permission. Immuta reads from the TAG_REFERENCES table function.

IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE

System account user

Tag ingestion

To ingest table, view, and column tag information from Snowflake, Immuta must have access to the SNOWFLAKE.ACCOUNT_USAGE.ACCESS_HISTORY view. See the Snowflake documentation for details.

USAGE ON DATABASE IMMUTA_DB
USAGE ON SCHEMA IMMUTA_DB.IMMUTA_PROCEDURES
USAGE ON SCHEMA IMMUTA_DB.IMMUTA_FUNCTIONS
USAGE ON FUTURE FUNCTIONS IN SCHEMA IMMUTA_DB.IMMUTA_FUNCTIONS
USAGE ON SCHEMA IMMUTA_DB.IMMUTA_SYSTEM
SELECT ON IMMUTA_DB.IMMUTA_SYSTEM.USER_PROFILE

PUBLIC role

All

Immuta has stored procedures and functions that are used for policy enforcement and do not expose or contain any sensitive information. These objects must be accessible by all users to facilitate the use and creation of policies or views to enforce Immuta policies in Snowflake.

SELECT ON IMMUTA_DB.IMMUTA_SYSTEM.ALLOW_LIST

PUBLIC role

All

Immuta retains a list of excepted roles and users when using the Snowflake integration. The roles and users in this list will be exempt from policies applied to tables in Snowflake to give organizations flexibility in case there are entities that should not be bound to Immuta policies in Snowflake (for example, a system or application role or user).

Maintaining state with Snowflake

The following user actions spur various processes in the Snowflake integration so that Immuta data remains synchronous with data in Snowflake. The list below provides an overview of each process:

Data source created: Immuta registers data source metadata and stores that metadata in the Immuta metadata database.
User account is mapped to Immuta: When a user account is mapped to Immuta, their metadata is stored in the metadata database.
User subscribed to a data source: When a user is added to a data source by a data owner or through a subscription policy, Immuta creates a role for that user (if a role for them does not already exist) and grants Snowflake privileges to their role.
Automatic subscription policy applied to or updated on a data source: Immuta calculates the users and data sources affected by the policy change and grants or revokes users' privileges on the Snowflake object. See the Protecting data page for details about this process.
Subscription policy deleted: Immuta revokes privileges from the affected roles.
Data policy created or updated: Snowflake row access policies and column masking policies are applied to the Snowflake object to reflect the Immuta policy. See the Protecting data page for details about this process.
Data policy deleted: Immuta removes the policy from the Snowflake object.
User removed from a data source: Immuta revokes privileges from the user's role.

Supported object types

Object type

Subscription policy support

Data policy support

Request app support

Table

✅

View

✅

Materialized view

✅

External table

✅

Event table

✅

Iceberg table

✅

Dynamic table

✅

Supported policies

The Snowflake integration allows users to author subscription and data policies to enforce access controls. See the corresponding pages for details about specific types of policies supported:

Supported Snowflake features

The Immuta Snowflake integration supports the following Snowflake features.

Private connectivity for Snowflake: While Immuta does not persist any of your data, data is temporarily held in memory in some instances, like when a user generates a data source fingerprint. This data is encrypted using TLS from the data source to Immuta as it traverses the public internet. Alternatively, Immuta can be connected to a user's Snowflake account over either AWS PrivateLink or Azure Private Link so that any data moving between the user's data source and the Immuta tenant is over a private network.
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.

Security and compliance

Authentication methods

The Snowflake integration supports the following authentication methods to register a connection. The credentials provided must be for an account with the permissions listed in the Register a Snowflake connection guide.

Key pair: Users can authenticate with a Snowflake key pair authentication.
Snowflake External OAuth: Users can authenticate with Snowflake External OAuth. For more information about this authentication option, see the Security and compliance guide.

User registration and ID mapping

The built-in Immuta IAM can be used as a complete solution for authentication and user entitlement. However, you can connect your existing identity management provider to Immuta to use that system for authentication and user entitlement instead. Each of the supported IAM protocols includes a set of configuration options that enable Immuta to communicate with the IAM system and map the users, permissions, groups, and attributes into Immuta.

For policies to impact the right users, the user account in Immuta must be mapped to the user account in Snowflake. You can ensure these accounts are mapped correctly in the following ways:

Automatically: If usernames in Snowflake align with usernames in the external IAM and those accounts align with an IAM attribute, you can enter that IAM attribute on the app settings page to automatically map user IDs in Immuta to Snowflake.
Manually: You can manually map user IDs for individual users.

For guidance on connecting your IAM to Immuta, see the how-to guide for your protocol.

Excepted roles/users

Excepted roles and users are assigned when the connection is registered, and no policies will apply to these users' queries, despite any Immuta policies enforced on the tables they are querying. Consequently, roles and users added to this list should be limited to service accounts.

How do excepted roles/users work?

Immuta excludes the listed roles and users from policies by wrapping all policies in a CASE statement that will check if a user is acting under one of the listed usernames or roles. If a user is on the list, then the policy will not be acted on the queried table. If the user is not, then the policy will be executed like normal. Immuta does not distinguish between role and username, so if you have a role and user with the exact same name, both the user and any user acting under that role will have full access to the data sources and no policies will be enforced for them.

When should you use excepted roles/users?

Add service accounts to the excepted roles/users list so that Immuta subscription and data policies will not unintentionally impact their jobs.
When using both tables and their views as data sources, add the owner of the view in Snowflake as an excepted role/user. Otherwise, the backing table's policies will be applied to that view.

Tag ingestion

You can enable Snowflake tag ingestion so that Immuta will 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.

Snowflake tag ingestion supports two authentication methods:

Username and password
Key pair

To enable Snowflake tag ingestion, see the Enable Snowflake tag ingestion page.

Credentials

If you want all Snowflake data sources to have Snowflake data tags ingested into Immuta, ensure the credentials provided on the Immuta app settings page for the external catalog feature can access all the data sources registered in Immuta. Any data sources the credentials do not have access to will not be tagged in Immuta. In practice, it is recommended to just use the same credentials for the connection and tag ingestion.

Caveats

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

Limitations and known issues

Snowflake workspaces are deprecated and are not supported with Snowflake table grants enabled, which is the default for all new connections.
If there are errors 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 register the connection will be able to access the data.
Once a Snowflake connection is deactivated 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.
When configuring one Snowflake instance with multiple Immuta tenants, the Snowflake system account for the connection must be unique in each Immuta tenant.
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 cannot get the column metadata 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 object sync job on the data source page.
If a user is created in Snowflake after that user is already registered in Immuta, Immuta does not grant usage on the per-user role automatically - meaning Immuta does not govern this user's access without manual intervention. If a Snowflake user is created after that user is registered in Immuta, the user account must be disabled and re-enabled to trigger a sync of Immuta policies to govern that user. Whenever possible, Snowflake users should be created before registering those users in Immuta.
Snowflake tables from imported databases are not supported. Instead, create a view of the table and register that view as a data source.
Data sources created from connections cannot be deleted. To remove the Immuta-applied policies from a Snowflake table, remove the policies from the data source, then disable it. To remove the Immuta-managed policies from all Snowflake tables, deactivate the connection.

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.

Requirement for a custom WHERE policy: The Immuta system account must have SELECT privileges on all tables/views referenced in a subquery via the system Snowflake role created by the setup script. Reach out to your Immuta support professional if you do not know the role to grant privileges to.

Subquery limitations

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

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.
For more information on the Snowflake subquery limitations see
- Understanding column-level security
- Understanding row access policies

Last updated 2 days ago

Was this helpful?