Immuta Integration With Snowflake

Snowflake Access Patterns

Immuta provides two types of Snowflake Access Patterns: Native Viewless Snowflake Access Pattern (Public Preview) and Native View-Based Access Pattern.

As shown from the diagram above, the new integration method (Viewless Snowflake access pattern) utilizes Snowflake’s row access and column based masking policies, as well as object tagging. While the previous integration method utilizes secure views to apply access control.

In this article, we’ll be discussing the new integration pattern only, please refer to IMMUTA documentation for more information about the old method.

Native Viewless Snowflake integration

In the Native Viewless Snowflake integration, Immuta manages and applies Snowflake Row Access Policies and Column Masking Polices without requiring views, allowing users to query tables directly in Snowflake while dynamic policies are enforced.

While Immuta controls subscription and data policies restricting who can see what and when, Immuta does not manage Snowflake grants on tables. This means that users are responsible for both

• registering the data source in Immuta and
• explicitly granting SELECT privileges on the table in Snowflake to the relevant users.

Note: When a data source is disabled or removed in Immuta or when the Snowflake integration is disabled in Immuta, these SELECT privileges must be revoked. Because Immuta removes policies on disabled and deleted data sources, any user who still has SELECT privileges will be able to query the unprotected data.

How to configure Immuta and Snowflake integration

Part 1. Snowflake user/role provisioning

At least two Snowflake users are required for each Snowflake environment, one user is used to create Immuta Snowflake integration (svc_immuta_int_sandpit)and the other user (svc_immuta_ds_sandpit) is used to create Immuta data source. See design consideration details in the table below.

source code can be found with below Github link:

https://github.com/suyah/snowflake-public/blob/main/immuta_user_role_creation.sql

Part 2. Immuta Settings

Step 1. Enable Native Snowflake Governance Controls (Viewless Snowflake Access Pattern)

Step 2. Create Snowflake Native Integration

Click on Test Snowflake Connection and then Save the settings.

Immuta Snowflake Integration Privileged user should be disabled once integration is done as it’s not used later when configuring data source and pushing policies.

Step 3. Create the first data source.

Step 4. Setup Subscriber Policy and Data Policies

projects created automatically after data source is created.

Step 5. Verify if policy is effective in Snowflake

Excluding service accounts in Immuta

While configuring Snowflake integration, there’s a field allows you to specify a list of roles/users to be excluded from Immuta policies. In our case, we’ll need to add our Snowflake service account (Snowflake local users, non AAD users) otherwise, they won’t be able to access Immuta protected tables.

Things to be followed up

Function related

1. How to deal with Snowflake Service Accounts which are local users, not AAD users. Those users are not visible in Immuta.
2. when Snowflake objects are added to IMMUTA as data source, those local users lost access by default as they cannot be added to IMMUTA’s subscription policy as well as data policies.
3. one possible approach is convert service accounts into AAD users. It requires testing
4. AAD user sync delay is observed — needs to restart provisioning in Azure to push the change
5. It needs to be addressed as it’s causing
6. Schema monitoring doesn’t seem working. Tables added to schema but is not added as new Data Source automatically in Immuta.

Security related

1. Currently Immuta Snowflake credentials are configured using password — stored in AWS secret manager, can be configured to switch to RSA keypair. Password rotation or keypair rotation is required.
2. Immuta SaaS makes ODBC connection to Snowflake via public internet. This is not a secure connection.
3. IMMUTA System account and system role should never be used by individual users.
4. IP Whitelisting to allow user login only from IMMUTA Server IP range (public IP of Immuta SaaS application or AWS VPC IP range if IMMUTA self-managed deployment)
5. Audit is required on anyone who switch to IMMUTA system role or login use IMMUTA system account.
6. Immuta Integration Privileged user should be disabled once integration is done as it’s not required for future data source configuration and policy deployment. — It’s tested successfully in this PoC but should be confirmed with IMMUTA before implement in PROD.