Getting Started with Snowflake: Phased Onboarding

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.

Several features allow you to gradually onboard data sources and policies in Immuta:

• Subscription policy of “None” by default: By default, no policy is applied at registration time; instead of applying a restrictive policy immediately upon registration, the table is registered in Immuta and waits for a policy to be applied, if ever.

  There are several benefits to this design:

  • All existing roles maintain access to the data and registration of the table or view with Immuta has zero impact on your data platform.
  • It gives you time to configure tags on the Immuta registered tables and views, either manually or through automatic means, such as Immuta’s sensitive data detection (SDD), or an external catalog integration to include Snowflake tags.
  • It gives you time to assess and validate the sensitive data tags that were applied.
  • You can build only row and column controls with Immuta and let your existing roles manage table access instead of using Immuta subscription policies for table access.

• Snowflake table grants coupled with Snowflake low row access policy mode (public preview): With these features enabled, Immuta manages access to tables (subscription policies) through GRANTs. This works by assigning each user their own unique role created by Immuta and all table access is managed using that single role.

  Without these two features enabled, Immuta uses a Snowflake row access policy (RAP) to manage table access. A RAP only allows users to access rows in the table if they were explicitly granted access through an Immuta subscription policy; otherwise, the user sees no rows. This behavior means all existing Snowflake roles lose access to the table contents until explicitly granted access through Immuta subscription policies. Essentially, roles outside of Immuta don't control access anymore.

  By using table grants and the low row access policy mode, users and roles outside Immuta continue to work.

  There are two benefits to this approach:

  • All pre-existing Snowflake roles retain access to the data until you explicitly revoke access (outside Immuta).
  • It provides a way to test that Immuta GRANTs are working without impacting production workloads.

Requirements

The following configuration is required for phased Snowflake onboarding:

• Impersonation is disabled
• Project workspaces are disabled

If either user impersonation or project workspaces 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:

   • Snowflake table grants (enabled by default)
   • Snowflake low row access policy mode

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.

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.