Native Data Clean Rooms¶

Snowflake Native Data Clean Rooms are designed for business arrangements where parties want to collaborate on sensitive or proprietary data without giving full access to the data. They provide a privacy-preserving environment for implementing a data collaboration agreement (data contract) between business users. Unlike Secure Data Sharing, where shared data can be used without restriction, clean rooms allow parties to collaborate while giving data providers additional controls that help protect their sensitive information.

Note

You can build your own clean room using the data clean room framework instead of using a Native Data Clean Room. However, building your own clean room requires additional technical expertise and does not have a web interface.

With a build-your-own clean room, you can specify exactly what data can be retrieved by a consumer (pre-defined access), which might be required if clean room participants are untrusted or semi-trusted.

For an example of how to build your own clean room using the data clean room framework, see the Build a Data Clean Room in Snowflake quickstart.

Introduction to Native Data Clean Rooms¶

Snowflake Native Data Clean Rooms allow data providers to securely share data while maintaining control of that data. By using a clean room, the data provider can regulate how a clean room participant can interact with the shared data. For example, when users query data in a clean room, they must formulate their queries to meet the requirements of the clean room, as defined by the data provider.

The restrictions imposed by a clean room are not so restrictive that it eliminates the usefulness of the shared data. The other party can join and enrich the shared data with their own data as long as it does not violate the clean room constraints.

Advantages of a clean room include:

Securely sharing data without having to copy or move data.
Sharing data while maintaining control of how others use it.
Providing flexibility that allows each party to customize how they want to filter, combine, and aggregate clean room data, within the constraints set by the data owner.
Providing the same clean room to multiple partners using private listings and the Snowflake Marketplace.

Clean room participants and workflow¶

Clean rooms use the concept of a provider and consumer, similar to other Snowflake features like Secure Data Sharing and the Native Apps Framework. The data owner is a provider who uses a clean room to safely share data and logic. This provider publishes the clean room as a listing so the consumer can install and use the clean room in their own account.

The following summarizes the tasks the provider and consumer complete as they collaborate with a clean room.

Provider:

Creates policies (outside of the clean room) that can be used by the clean room to control what the consumer can do with the data.
Creates the clean room, sharing the data objects (tables and views) and application logic (stored procedures and user-defined functions) that will be available to consumers in the clean room.
Assigns existing policies to the shared tables and views.
Tests the clean room in their own account to make sure it is ready to distribute to consumers.
Releases the clean room so it can be scanned for security and packaged for distribution.
Publishes the clean room so consumers can install it in their own accounts.

Consumer:

Installs the clean room from a private listing or from the Snowflake Marketplace, depending on how the provider published it.
Executes queries against the shared data, including joining and enriching it with their own data. Can also run stored procedures and functions provided by the clean room.

The consumer can install multiple clean rooms (from one or more providers), which allows a query in the consumer’s account to work with data from multiple parties, including the consumer’s own data, within a privacy-preserving environment. However, the consumer cannot install a clean room more than once from the same listing.

Control of your data¶

Clean rooms restrict what a consumer can do with the data you are sharing. The ability to place restrictions on shared data comes from assigning policies to a table or view.

About policies¶

Policies are assigned to tables and views. When you use a clean room to share data, you can use policies to maintain control of what can be done with the data. For example, policies can force a consumer to form their queries in a particular way or hide individual records from query results.

The following policies can be assigned to tables and views in a clean room:

Aggregation policy - Requires consumers to aggregate results rather than return individual records.
Projection policy - Prevents consumers from returning (projecting) values from a particular column of a table, while allowing them to filter on that column.
Row access policy - Prevents consumers from accessing specific records returned by a query. Requires Enterprise Edition or higher.

Note

Because a clean room is built on the Snowflake Native App Framework, the body of a policy that is used within a clean room must conform to the same restrictions as the setup script of a Snowflake Native App, including the use of context functions. For a list of these restrictions, see Restrictions on the setup script and Limitations when calling context functions from the setup script.

There are two categories of policies in a clean room:

App-level policy:

Policy that is applied to a data object (table or view) within the clean room, which limits its scope to the clean room. An app-level policy restricts data in the clean room without affecting access to the table or view in the provider’s account or a consumer outside of the clean room (if the same table or view is shared using secure data sharing or a different clean room).

Object-level policy:

Policy that is applied to a data object outside of the clean room. A provider can assign a policy to a table or view independent of creating a clean room. As a result, the user creating a clean room might include a table or view that is already constrained by a policy. Within a clean room, these are known as object-level policies.

Object-level policies cannot be removed from a data object from within the clean room. As a result, access to tables and views in the clean room cannot be more permissive than access to them in the provider’s account. The object-level policy can be removed from a table or view using SQL in the provider account, which affects both the provider account and the clean room.

A clean room can include both categories for a particular type of policy. For example, a table in a clean room could be constrained by both an app-level aggregation policy and an object-level aggregation policy. When a data object has an object-level policy and an app-level policy of the same type, queries against the object must meet the requirements of the more restrictive policy.

Shared logic¶

With clean rooms, providers can do more than share data with consumers. They can also share logic designed to extract value from the shared data. Shared application logic can include:

Note

Because a clean room is built on the Snowflake Native App Framework, application logic in a clean room must conform to the same restrictions as the setup script of a Snowflake Native App. For a list of these restrictions, see Restrictions on the setup script and Limitations when calling context functions from the setup script.

Changes to objects outside of a clean room¶

The data, policies, and logic included in a clean room continue to exist outside of the clean room, and can continue to change. How the clean room handles these changes depends on the item being modified.

Data Objects:

A clean room is updated automatically with changes to tables and views. For example, if new data is added to a table outside of the clean room it is automatically available to the clean room consumer. Similarly, if a column is added or removed from a table outside of the clean room, the consumer experiences the change automatically. As a result, removing a column from a table in the provider account could break a consumer’s queries in the clean room.

If a policy is assigned or detached from a table or view in the provider account, the restrictions of the clean room change accordingly.

Policies:

A clean room is updated automatically when someone changes a policy outside of the clean room. As a result, if someone in the provider account modifies a policy, including an app-level policy, the constraints of the clean room change instantly without automatic notification to the consumer.

Application Logic:

For application logic like stored procedures and user-defined functions, the clean room contains a copy of the logic that exists in the provider account. As a result, the clean room must be manually updated if the provider modifies the logic and wants to include the new version in the clean room.

Built using the Native Apps Framework¶

A Snowflake Native Data Clean Room is a specialized app created with the Native App Framework. While this implementation detail is mostly transparent, it explains, for example, why the clean room is identified as an application package in Provider Studio and is installed as an app.

Because a clean room is an app, a user who is familiar with the Native Apps Framework could use SQL instead of Snowsight to work with the clean room. For example, the consumer could use SHOW APPLICATIONS to view the installed clean room.

Important

While it is safe to use SQL to view the clean room app, using SQL to make changes is discouraged as it can have unintended consequences for those using Snowsight to work with the clean room.

Considerations and Limitations¶

Keep the following considerations and limitations in mind when using Snowflake Native Data Clean Rooms.

Considerations¶

A clean room allows a provider to configure how their data is used, but it is their responsibility to understand what data is being shared, and to configure and test a clean room before inviting others to use it.
A clean room allows a provider to share non-secure objects, which can unintentionally leak data. For examples of how a non-secure view can leak data, see Working with Secure Views.

Limitations¶

Consumers of the clean room must be in the same region as the data provider.
Clean rooms cannot contain row access policies that use mapping tables.
You cannot use SQL instead of Snowsight to create a clean room.
You cannot include data objects (tables and views) or application logic (stored procedures and functions) from more than one database. If you change databases when modifying the clean room, the original objects will be replaced with the objects from the new database.
Clean rooms cannot contain data objects and application logic with names that include special characters.
The schema name cannot contain more than 248 characters.
Clean rooms inherit the limitations of the Snowflake Native App Framework. Not all of the limitations are relevant to creating, sharing, and using clean rooms, but details like available regions and naming conventions are useful to know. For details, see:
- General limitations: Known limitations
- Limitations on policies and application logic in a clean room: Restrictions on the setup script and Limitations When Calling Context Functions from the Setup Script.
- Limitations on data objects in a clean room: Database Objects That Can Be Shared with an Application Package

Create and share a clean room as a provider¶

To create a clean room and share it with consumers, a provider must complete the following tasks:

Create a clean room, including selecting which data objects and application logic will be available to a consumer in the clean room.
Assign policies to tables and views to control what the consumer can do with the shared data. Adding policies to a clean room assumes those policies already exist.
Test the clean room in the provider’s local account to be sure it is ready to be distributed.
Release the clean room so it can be scanned and packaged.
Publish the clean room as a listing so consumers can install and use it. This can be a private listing shared with a select group of clean room participants or a listing on the Snowflake Marketplace, where the clean room can be discovered and installed by all registered Snowflake consumers.

Access control privileges¶

A user needs the CREATE APPLICATION PACKAGE privilege to create a clean room.

In addition, users need the privileges required to work with the data objects, application logic, and policies in the clean room. For example, if a user does not have privileges to work with a database in the provider account, they cannot add objects from the database to the clean room. Similarly, if users do not have privileges to assign policies to tables in the provider account, they cannot assign policies in the clean room.

Create a clean room¶

To create a new clean room, including selecting which data objects and application logic will be shared in the clean room:

Sign in to Snowsight.
Switch to a role that has the CREATE APPLICATION PACKAGE privilege.
In the navigation menu, select Projects » App Packages.
Select Create » Clean Room.
Select + Add Objects, and begin adding the data objects and application logic that you want to include in the clean room. Data objects are the tables and views that you want to share in the clean room. Application logic includes the stored procedures and functions that the consumer can use to work with the shared data.
For each object you want to share, ensure you have the proper access control privileges, and then:
1. Select the database and schema that contains the object that you want to add to the clean room.
2. Select one or more objects in the schema.
3. Select Done.
Accept the proposed Clean Room Name, or enter a custom one. The final name of the application package within the provider account is based on this name.
In the Display Title field, enter the clean room name as it will appear in the Readme file that is distributed with the clean room.
Select the warehouse that will provide the compute resources needed to create, modify, and package a clean room. Snowflake recommends an XS warehouse for this purpose. If you have a default warehouse, it is pre-selected, but can be changed.
Select Create.

Assign policies¶

You can assign the following policies to the tables and views in the clean room in order to restrict how consumers use the data in the clean room:

Aggregation Policy
Projection Policy
Row Access Policy

A policy must already exist in order to add it to a table or view in the clean room.

Assigning policies in a clean room is governed by the same rules that govern assigning policies in a provider account. For example, only one aggregation policy can be assigned to a single table or view regardless of whether it is in a clean room or in the provider account.

The access control privileges needed to assign a policy in the clean room are the same as those needed to assign the policy to a table or view in the provider account.

Each policy you import into the clean room is assigned to a data object as an app-level policy because its scope is limited to the clean room, which is an app in the Native Apps Framework. An app-level policy restricts data in the clean room without affecting access to the table or view in the provider’s account.

For more information about policies, including the difference between app-level and object-level policies, see About policies.

Assign an app-level aggregation policy¶

When an aggregation policy is assigned to a table, queries against that table must aggregate data in order to return results. Requiring that all data be aggregated into groups prevents queries from returning data from individual records. An aggregation policy specifies the minimum number of records that must be included in a group.

To learn how to create an aggregation policy so it can be added to a clean room, see Creating an Aggregation Policy.

To assign an aggregation policy to a data object in the clean room:

Sign in to Snowsight.
Select Projects » App Packages.
Select the name of the clean room.
In the Tables & Views section, find the data object you want to constrain with an aggregation policy, and then select the pencil icon to edit.
In the App-level Policies section, select Import » Aggregation Policy.
Select the aggregation policy you want to apply to the data object.
Select Save.

Assign an app-level projection policy¶

A projection policy prevents a query from returning (projecting) values from a particular column of a table or view. The policy allows a query to filter upon a column while blocking attempts to return values from it.

To learn how to create a projection policy so it can be added to a clean room, see Creating a Projection Policy.

To assign a projection policy to a data object in the clean room:

Sign in to Snowsight.
Select Projects » App Packages.
Select the name of the clean room.
In the Tables & Views section, find the data object you want to constrain with a projection policy, and then select the pencil icon to edit.
In the App-level Policies section, select Import » Projection Policy.
Select the projection policy you want to apply to the data object, and then select Next.
Use the + Select button to choose which column is protected by the projection policy.
Select Save.

Assign an app-level row access policy¶

A row access policy determines which rows in a table or view are returned in query results. For example, if a user executing a query does not meet criteria defined in the row access policy, then certain rows will be omitted from the results.

Note

Row access policies require Enterprise Edition or higher. If your account is not Enterprise Edition or higher, you do not have the option to add row access policies.

To learn how to create a row access policy so it can be added to a clean room, see CREATE ROW ACCESS POLICY. You can also review an example of creating a row access policy.

To assign a row access policy to a data object in the clean room:

Sign in to Snowsight.
Select Projects » App Packages.
Select the name of the clean room.
In the Tables & Views section, find the data object you want to constrain with a row access policy, and then select the pencil icon to edit.
In the App-level Policies section, select Import » Row Access Policy.
Select the row access policy you want to apply to the data object, and then select Next.
Assign a column to each argument.
Select Save.

Test a clean room¶

When you are finished adding objects to the clean room and assigning policies to the tables and views, it is best to test the clean room in your own account before distributing it to consumers.

To install the clean room in your local account and begin testing:

Sign in to Snowsight.
Select Projects » App Packages.
Select the name of the clean room.
Select Test Locally.

The Readme file appears when the clean room is installed and ready to test.
From the upper toolbar, select Open in worksheet and begin testing by running queries against the data objects and executing stored procedures and functions.
Use the left navigation to review the shared data objects and application logic.

Once the clean room is installed in your local account, it is available from Data Products » Apps in the navigation menu.

You can also do the following to review the data objects and application logic that have been shared:

Sign in to Snowsight.
Select Data » Databases.
Expand the name of the application package associated with the clean room. The application package consists of the Clean Room Name prepended with DCR and appended with DRAFT.

Release a clean room¶

Once you have tested your clean room, you are ready to release the clean room. Releasing the clean room does not publish it for consumers to install, but rather prepares it for publication by performing a security scan and packaging it into an app.

To release the clean room:

Sign in to Snowsight.
Select Projects » App Packages.
Select the name of the clean room.
Select Release.
Confirm by selecting Release.

It can take a a considerable amount of time for Snowflake to perform a security scan of the clean room. You can select the Refresh icon to check whether the scan and packaging is complete.

Publish a clean room¶

A clean room must be published as a listing before consumers can install and use it. Before publishing, you must decide who is going to use the clean room:

To share the clean room with a select group of clean room participants, publish it as a private listing.
To share the clean room with all Snowflake consumers, publish it to the Snowflake Marketplace.

Because clean rooms are built on the Native Apps Framework, publishing the clean room as a listing is the same as publishing an application package.

To share the clean room with consumers:

In the clean room, select Publish.
Once Provider Studio opens, refer to Create a listing for an application package to help you complete the process. Be sure to select the clean room as the application package when prompted by the listing.

Manage a clean room as a provider¶

This section describes how a provider can update and delete a clean room.

Important

A provider is responsible for notifying consumers when a clean room changes. The consumer is not automatically notified if the provider modifies application logic or a policy, which can significantly alter the constraints and functionality of the clean room.

Changes to data and policies in the provider account (outside the clean room) can have an effect on the consumer’s experience even though the provider has not altered the clean room itself. For more details, see Changes to objects outside of a clean room

Update a clean room¶

To open an existing clean room, use the navigation menu to select Projects » App Packages, then select Packages.

Once opened, you can make the following changes to the clean room:

Task	Action
Add/remove data objects and application logic	Select Manage » Add or remove objects. Select or deselect the object. Test and release the draft.
Update existing application logic	Update the stored procedure or function in the provider account outside of the clean room. Select Manage » Re-sync Objects to bring those changes into the clean room. Test and release the draft.
Add/remove an app-level policy	Find the data object under Tables & Views, and select the pencil icon to edit. Delete or import the policy. The consumer experiences the change automatically after a short waiting period.
Update an app-level policy	Update the policy in the provider account. The consumer experiences the change automatically after a short waiting period.
Update the name of the clean room as it appears in the Readme file	Select Manage » Edit Display Name.

Work with drafts¶

When you modify the data objects and application logic of a released or published clean room, a draft version of the clean room is created. The changes appear under Draft Changes. Note that changes to policies are applied immediately, and do not create a draft version of the clean room.

To accept the changes in the draft version and update the clean room:

After making changes, wait for the security scan to complete. You can select the Refresh button to check whether the scan is done.
Select Test Locally » Draft Version to test the draft version of the clean room.
Select Release Updates to update the clean room.

If the updated clean room was previously published and installed, the consumer experiences the changes automatically after a short waiting period.

Delete a clean room¶

Deleting a clean room removes its application package from the provider account. It also removes the clean room from consumer accounts.

To delete a clean room:

Sign in to Snowsight.
In the left navigation bar, select Projects » App Packages.
Select the name of the clean room.
If the clean room has already been published, you must unpublish and delete the listing associated with the clean room:
1. Select the Associated Listings tab, then select the name of the listing you need to delete.
2. In the top-right corner, select Live » Unpublish.
3. Select Delete.
If you used Provider Studio to delete a listing, return to the clean room by selecting its name from Projects » App Packages.
In the upper toolbar, select … (More), and then select Drop.

Use a clean room as a consumer¶

Once the provider has published the clean room as a listing, the consumer can install it in their own account.

The process of installing the clean room varies depending on whether the providers shared it as a private listing or published it on the Snowflake Marketplace.

Prerequisite:: The clean room consumer must be registered as a Snowflake Consumer before installing the clean room.

Install a clean room from a privately shared listing¶

To install a clean room from a private listing:

Sign in to Snowsight.
In the navigation menu, select Data Products » Apps.
In Recently shared with you, select the tile for the listing for the clean room. If the clean room is not listed, search for it instead.
Select Get, or for a monetized clean room, select Buy.
Select Get.
Select Open to view the Readme file of the clean room. From there, you can start using the clean room.

Install a clean room from a Snowflake Marketplace listing¶

To install a clean room from a Snowflake Marketplace listing:

Sign in to Snowsight.
In the navigation menu, select Data Products » Marketplace.
Search or browse to the listing you want to access.
Select the listing.
Select Get to access the listing.
Select the warehouse that you want to use to install the application.
Select Get.
Select Open to view the Readme file of the clean room. From there, you can start using the clean room.

Execute queries in the clean room¶

To start using an installed clean room:

Sign in to Snowsight.
In the navigation menu, select Data Products » Apps.
Select the clean room, which opens the Readme file.
From the upper toolbar, select Open in worksheet, then run queries against the data objects and execute stored procedures and functions.

With the worksheet open, you can use the left navigation to review the data objects and application logic that has been shared in the clean room. The name of the clean room’s app is based on the name of the clean room that appears in the Readme file.

Tip

For help writing a query that meets the requirements of an aggregation policy in the clean room, see Query Requirements.