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.
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.
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.
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.
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.
Audience: Project Owners and members
Content Summary: This tutorial configures a .
Use Case
Compliance Requirement: Users can only WRITE to specified locations in Dev, and these users need to share this data with other Dev users.
After Dev users have analyzed data, they need to write content back to Immuta and share it with other Dev users. To allow them to write data back to Immuta, project owners need to create workspaces for their projects. Then, users can share the data they've written to Immuta with other users as derived data sources.
Workspaces can be enabled in the New Project modal when creating a new project, but project owners can enable this feature at any point on the project's Policies tab.
Navigate to the Policies tab and enable Project Equalization by clicking the Project Equalization slider to on.
Scroll to the Native Workspace section and click Create.
Select Snowflake from the Workspace Configuration dropdown menu.
Name the Workspace Schema. By default, the schema name is based off of the project name, but you can change it here. Your project workspace will exist within this schema under Snowflake under the database configured by the Application Admin.
Use the dropdown menu to select the Hostname. Projects can only be configured to use one Snowflake host.
Select one or more Warehouses to be available to project members when they are working in the Snowflake workspace.
Click Create to enable the workspace.
Once the workspace is created, project members will see relevant data sources in the Snowflake UI when working under the project context.
Select the Role created by the project workspace. The role created will be a combination of the database name (configured by the Application Admin) and the schema name (set in the previous section by the project owner).
Create a table in Snowflake.
Now that data has been written to the workspace, users can share this data with others by making it a derived data source in Immuta.
Scroll to the Native Workspace section on the Policies tab and click the toggle to disable the workspace.
Click Delete in the Native Workspace section.
Choose one of the following options in the modal:
Purge Generic Workspace Data: permanently delete data, while the data used by derived data sources is preserved. Note: If you created a derived data source that references a view on top of a table in Snowflake that isn't a derived data source, that table will be deleted and break the derived data source.
Purge Everything & Delete Derived Data Sources: permanently delete data and purge all derived data sources.
Click Delete.
If you had project workspaces that were created before Immuta 2022.1.0, you need to perform this migration.
Navigate to the Policies tab of you project.
Toggle the switch to disable the workspace, and choose from the purge options.
Refresh the page.
Toggle the switch the enable the workspace, and fill out the modal.
Audience: Project members
Content Summary: This page outlines prerequisites and provides an overview of the integration process for Snowflake project workspaces.
See the Overview page for information on the utility of project workspaces and the Configuration page for installation instructions.
External IDs have been connected with an IAM or manually mapped in for Snowflake.
Data sources registered by Excepted Roles: Snowflake workspaces generate static views with the credentials used to register the table as an Immuta data source. Those tables must be registered in Immuta by an Excepted Role so that policies applied to the backing tables are not applied to the project workspace views.
An Immuta User with the CREATE_PROJECT permission creates a new project with Snowflake data sources.
The Immuta Project Owner enables Project Equalization which balances every Project Members’ access to the data to be the same.
The Immuta Project Owner creates a Snowflake Project Workspace which automatically generates a subfolder in the root path specified by the Application Admin and remote database associated with the project.
Project members can access data sources within the project and use WRITE to create derived tables. To ensure equalization, users will only see data sources within their project as long as they are working in the Snowflake Context.
The CREATE_DATA_SOURCE_IN_PROJECT permission is given to specific users so they can expose their derived tables in the Immuta project; the derived tables will inherit the policies, and then the data can be shared outside the project.
If a project member leaves a project or a project is deleted, that Snowflake Context will be removed from the user's Snowflake account.
Immuta only supports a single root location, so all projects will write to a subdirectory under this single root location.
If an administrator changes the default directory, the Immuta user must have full access to that directory. Once any workspace is created, this directory can no longer be modified.