Snowflake Immuta Integration Prerequisite Checklist

Introduction

This prerequisite checklist ensures proper preparation of the Snowflake and Immuta environments, minimizing any obstacles or delays during the integration process.

  1. Private Link Setup

    • For Immuta SaaS, will this tenant need to set up PrivateLink connectivity?

      • AWS PrivateLink - more detail here and ensure the following:

        • Obtain Snowflake PrivateLink config (e.g. select SYSTEM$GET_PRIVATELINK_CONFIG())

        • Snowflake account is on AWS

        • Snowflake account is on Business Critical Edition+

        • The ACCOUNTADMIN role is available to configure PrivateLink.

      • Azure Private Link - more detail here and ensure the following:

        • Obtain Snowflake PrivateLink config (e.g. select SYSTEM$GET_PRIVATELINK_CONFIG())

        • Snowflake account is on Azure

        • Snowflake account is on Business Critical Edition+

        • The ACCOUNTADMIN role is available and ready to configure on Snowflake. (e.g. SELECT SYSTEM$AUTHORIZE_PRIVATELINK ( '/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Network/privateEndpoints/abc12345.east-us-2.azure.snowflakecomputing.com-eus2', '<ACCESS_TOKEN>' ); )

  2. Snowflake Permissions Required

    • Obtain the necessary Snowflake permissions to set up the integration?

      • Several SQL statements on bootstrap script require the ACCOUNTADMIN or a Role to properly configured the integration. Such as:

        • Applying column masking policies, e.g. APPLY MASKING POLICY

        • Applying row access policies at the account level, e.g. APPLY ROW ACCESS POLICY

        • TableGrant feature requires, e.g. MANAGE GRANTS ON ACCOUNT WITH GRANT OPTION

  3. Integration Method

    • Will this be an automated or manual integration?

      • If automated, confirm that Immuta will manage the setup. This usually requires a Snowflake role with sufficient permissions to execute specific SQL statements successfully on Snowflake.

      • If manual, ensure the customer is prepared to run the integration-bootstrap script to configure integration database in Snowflake. These are some of the specific SQL statements needed to be executed on Snowflake.

        • Review the bootstrap script - it can be downloaded through Immuta UI after filling out the Snowflake information but not saving the integration record entry on Immuta.

        • The bootstrap script creates an integration database on Snowflake, and including a db_SYSTEM role, an user db_SYSTEM_ACCOUNT, functions, procedures, schemas and other objects that manages the integration.

  4. TableGrants and LowRAP(row access policiues)

    • Review and be informed about Table Grants + Low-RAP features.

      • This feature allows Immuta to streamline and manage table grants on Snowflake. Additionally, the LowRAP feature improves somer query performance by decreasing the number of Snowflake row access policy objects where not necessary. For example, a SELECT * FROM TABLE query may not need to trigger authorization checks against Snowflake row access policy object for every row of data queried from the table.

  5. Snowflake Query Audit Logs

    • Review Snowflake Query Audit Logs configuration.

      • This feature requires this permission on Snowflake: IMPORTED PRIVILEGES ON DATABASE

      • Immuta queries Snowflake views QUERY_HISTORY and ACCESS_HISTORY for audit logs. Note: that both of these two Snowflake views have build-in latency of 1-4 hours; consequently, audit logs extracted to Immuta will inherit same latency - this made Immuta's Snowflake audit logs to be non-live data.

      • Audit logs run every 24 hours. While the interval can be adjusted for more frequent checks, Immuta does not recommend setting it too low, as it may trigger background jobs that could impact future tasks.

  6. Snowflake Tags Ingestion

    • Will the integration be using Snowflake Tags in Immuta? If so,

      • Consider to setup Snowflake Data Catalog before any datasource ingestion to Immuta.

      • Note: The Snowflake Data Catalog integration will ingest all Snowflake tags:tag-values from the Snowflake acount to Immuta.

  7. Snowflake Datashare Database

    • Will the integration be working with Snowflake Datashare database? OUTBOUND or INBOUND

    • Identify what and where the Datashare database is in. Identify whether Immuta will work and manage the datashare on consumer-account or producer-account.

      • Beware that users @producer-account are different than @consumer-account even if user has same login-name on both accounts.

      • Note that Snowflake supports same region and same cloud provider datashare. If data are in accounts in different region or different cloud provider, then data will need be moved to the support enviornment first.

      • Immuta TableGrants+LowRAP feature can play a part on Snowflake datashare.

      • Immuta can also provide fine-graned access control on database of datashare object - depending on setup.

  8. Documentation Review Recommendation

    • Review the Snowflake-Immuta Integration Setup Guide?

      • Go through the official Snowflake-Immuta integration documentation thoroughly and note any questions or concerns.

      • Generate the bootstrap-script and review it thoroughly to understand what SQL statements are executed to setup the integration framework and Immuta integration database on Snowflake.

      • For new Immuta tenants, Snowflake integration set up can be a breeze, and the integration can be easily disabled, removed, and redone. If there are no datasource ingested to Immuta yet, setting up the integration typically have minimal impact on Snowflake. Immuta will send a set of SQLs to Snowflake to create the integration database, including a db_SYSTEM role, an user db_SYSTEM_ACCOUNT, functions, procedures, schemas and other objects that manages the integration.

Last updated