Skip to content

Getting Started with Snowflake

Use Case

While you're onboarding Snowflake data sources and designing policies, you don't want to disrupt your Snowflake users' existing workflows.

Instead, you want to gradually onboard Immuta through a series of successive changes that will not impact your existing Snowflake users.

A phased onboarding approach to configuring the Snowflake integration ensures that your users will not be immediately affected by changes as you add data sources and configure policies.

See the Phased Snowflake onboarding conceptual guide for an explanation of the benefits of this approach and descriptions of the features that allow you to gradually onboard data sources and policies in Immuta.

Requirements

The following configuration is required for phased Snowflake onboarding:

  • Impersonation is disabled
  • Project workspaces are disabled

If either of these capabilities is necessary for your use case, you cannot do phased Snowflake onboarding as described below.

Configure your Snowflake integration

  1. Configure your Snowflake integration with the following features enabled:

  2. Select None as your default subscription policy.

Register data and validate tags

  1. Plan the policies you need to have in place, the tags that will apply to your data, and how the tags will be applied to your data.
  2. Enable sensitive data discovery (SDD).
  3. Register a subset of your tables to configure and validate SDD.
  4. Configure SDD to discover entities of interest for your policy needs.
  5. Validate that the SDD tags are applied correctly.
  6. Register your remaining tables at the schema level with schema detection turned on. This setting allows Immuta to continuously monitor for schema changes (new tables, column, dropped tables, columns, changed column types).
  7. Let SDD or external catalog synchronization complete, and then validate that SDD tags are applied correctly.
  8. Further customize SDD as necessary.

Write policies

At this point, no policies are in place because of the default subscription policy setting. Now you can write and apply the policies you planned. You do not have to do all policies at once.

In the steps below, you do not have to validate every policy you create in Immuta; instead, examine a few to validate the behavior you expect to see.

Subscription policies

Subscription policies grant or revoke access to Snowflake tables.

If necessary, you could use your existing roles for table access and only use Immuta for row access policies and masking policies.

Info

Immuta roles are created for users once they are subscribed to a table by a policy. SECONDARY ROLES ALL allows you to combine warehouse access with the Immuta role.

  1. Create a global subscription policy.
  2. Validate that the Immuta users impacted now have an Immuta role in Snowflake dedicated to them.
  3. Validate that when acting under the Immuta role those users have access to the table(s) in question.
  4. Validate that users without access in Immuta can still access the table with a different Snowflake role that has access.

  5. Validate that a user with SECONDARY ROLES ALL enabled retains access if

    • they were not granted access by Immuta and
    • they have a role that provides them access, even if they are not currently acting under that role.

Data policies

Data policies enforce fine-grained access controls on a table (for example, row access policies or masking policies).

  1. Create a global data policy.
  2. Validate that a user with a role that can access the table in question (whether it's an Immuta role or not) sees the impact of that data policy.

Remove or alter old roles

Once all Immuta policies are in place, remove or alter old roles.

  1. Delete irrelevant roles instead of revoking access to avoid confusion.
  2. Ensure deleting roles will not have other implications, like impacting warehouse access. If deleting those roles will have unintended effects alter those roles to remove the access control logic instead of deleting them.