Skip to content

You are viewing documentation for Immuta version 2022.5.

For the latest version, view our documentation for Immuta SaaS or the latest self-hosted version.

cancel

Snowflake Project Workspaces

Audience: Project members

Content Summary: This page explains Snowflake project workspaces, which allow users to access protected data in and write data to Snowflake.

See the Pre-Configuration Checklist for details on prerequisites and the Configuration page for installation instructions.

Overview

Combining Immuta projects and Snowflake workspaces allows users to access and write data directly in Snowflake.

With Snowflake workspaces, Immuta enforces policy logic on registered tables and represents them as secure views in Snowflake. Since secure views are static, creating a secure view for every unique user in your organization for every table in your organization would result in secure view bloat; however, Immuta addresses this problem by virtually grouping users and tables and equalizing users to the same level of access, ensuring that all members of the project see the same view of the data. Consequently, all members share one secure view.

While interacting directly with Snowflake secure views in these workspaces, users can write within Snowflake and create derived data sources, all the while collaborating with other project members at a common access level. Because these derived data sources will inherit all of the appropriate policies, that data can then be shared outside the project. Additionally, derived data sources use the credentials of the Immuta system Snowflake account, which will allow them to persist after a workspace is disconnected.

Snowflake workspaces can be used on their own or with the Snowflake integration.

Policy Enforcement

Immuta enforces policy logic on data and represents it as secure views in Snowflake. Because projects group users and tables and equalize members to the same level of access, all members will see the same view of the data and, consequently, will only need one secure view. Changes to policies immediately propagate to relevant secure views.

Mapping Projects to Secure Views

Immuta projects are represented as Session Contexts within Snowflake. As they are linked to Snowflake, projects automatically create corresponding

  • roles in Snowflake: IMMUTA_[project name]
  • schemas in the Snowflake IMMUTA database: [project name]
  • secure views in the project schema for any table in the project

To switch projects, users have to change their Snowflake Session Context to the appropriate Immuta project. If users are not entitled to a data source contained by the project, they will not be able to access the Context in Snowflake until they have access to all tables in the project. If changes are made to a user's attributes and access level, the changes will immediately propagate to the Snowflake Context.

Because users access data only through secure views in Snowflake, it significantly decreases the amount of role management for administrators in Snowflake. Organizations should also consider having a user in Snowflake who is able to create databases and make GRANTs on those databases and having separate users who are able to read and write from those tables.

Benefits

  • Few roles to manage in Snowflake; that complexity is pushed to Immuta, which is designed to simplify it.
  • A small set of users has direct access to raw tables; most users go through secure views only, but raw database access can be segmented across departments.
  • Policies are built by the individual database administrators within Immuta and are managed in a single location, and changes to policies are automatically propagated across thousands of tables’ secure views.
  • Self-service access to data based on data policies.
  • Users work in various contexts in Snowflake natively, based on their collaborators and their purpose, without fear of leaking data.

  • All policies are enforced natively in Snowflake without performance impact.

    • Security is maintained through Snowflake primitives (roles and secure views).
    • Performance and scalability is maintained (no proxy).

  • Policies can be driven by metadata, allowing massive scale policy enforcement with only a small set of actual policies.

  • Derived tables can be shared back out through Immuta, improving collaboration.
  • User access and removal are immediately reflected in secure views.

Limitations