Share data content in a Snowflake Native App¶

About shared data in a Snowflake Native App¶

The Snowflake Native App Framework allows providers to add shared data content to an app. This data content is shared with the consumers when they install and use the app. To share data content, providers must grant privileges on the shared data to the application package. Data content that providers share with an application package is shared across all installed instances of the app.

Consumers cannot access shared content directly. Instead, a provider creates a secure view in the setup script of an application package and grants the consumer access to the secure view. For details, see Allow consumers to access shared objects in an app.

Grant privileges on shared content to an application package¶

To include shared data content in an app, providers must grant privileges on the object to be shared with the application package. When providers add an object to an application package, by default, the object is private to the application package and not visible when the app is installed.

To make objects visible to an app installed from the application package, use the GRANT … TO SHARE IN APPLICATION PACKAGE command as shown in the following example:

CREATE APPLICATION PACKAGE app_package;

GRANT USAGE ON SCHEMA app_package.shared_schema
  TO SHARE IN APPLICATION PACKAGE app_package;
GRANT SELECT ON TABLE app_package.shared_schema.shared_table
  TO SHARE IN APPLICATION PACKAGE app_package;

In this example, the first command grants the USAGE privilege on the shared_schema schema to the application package. This command allows the schema to be shared with consumers. The second command grants the SELECT privilege on the shared_table table within shared_schema to the application package. This command allows consumers to query the table.

After a consumer installs an app from the application package app_package, they can access the shared_schema and query the shared_table.

You can also share views with an app by using similar SQL commands.

Grant privileges on objects outside the application package¶

To share a database object that exists outside the application package, providers must create views in the application package that allow access the object. You cannot share objects outside the application package directly with app installed in the consumer account.

For example, to share a database that is outside the application package, grant the REFERENCE_USAGE privilege on the database to the application package as shown in the following example:

GRANT REFERENCE_USAGE ON DATABASE other_db
  TO SHARE IN APPLICATION PACKAGE app_pkg;

After granting the REFERENCE_USAGE on the external database, a provider must create a view within the application to references the shared objects as shown in the following example:

CREATE VIEW app_pkg.shared_schema.shared_view
  AS SELECT c1, c2, c3, c4
  FROM other_db.other_schema.other_table;

This command creates a view in the application package that references the database, table, and schema that are outside the application package.

After creating the view, you must grant privileges on the schema and view to the application as shown in the following example:

GRANT USAGE ON SCHEMA app_pkg.shared_schema
  TO SHARE IN APPLICATION PACKAGE app_pkg;
GRANT SELECT ON VIEW app_pkg.shared_schema.shared_view
  TO SHARE IN APPLICATION PACKAGE app_pkg;

Allow consumers to access shared objects in an app¶

Database objects that are created in the setup script are directly accessible to the app after installation. These include tables, functions, procedures, and new view definitions,

However, by default, database objects shared with an application package are not visible to consumers. To allow consumers to view and access data content, the application package must create a secure view and grant the appropriate privileges.

This approach offers the following advantages:

• Creating the view in the setup script ensures that changes made directly to the shared objects, such as new columns, are not visible to the version of the Snowflake Native App being installed by the setup script. To allow access to changes to the object, providers must create a new version or patch for the app.

• Creating the view in a versioned schema ensures that each version of the Snowflake Native App contains only the definition of the view for that version. This is important for upgrade scenarios.

To expose shared objects to a consumer, the setup script must include commands to:

• Install views within a versioned schema in the application package.

• Grant access to those views to the consumer using an application role.

The following example describes how to use application roles to grant access to shared objects within the setup script of the application package:

CREATE APPLICATION ROLE app_user;

CREATE OR ALTER VERSIONED SCHEMA inst_schema;
GRANT USAGE ON SCHEMA inst_schema
  TO APPLICATION ROLE app_user;

CREATE VIEW IF NOT EXISTS inst_schema.shared_view
  AS SELECT c1, c2, c3, c4
  FROM shared_schema.shared_table;

GRANT SELECT ON VIEW inst_schema.shared_view
  TO APPLICATION ROLE app_user;

In this example, the view accesses content in the shared_schema.shared_view and shares it with the application package.

Define policies on proxy views¶

Snowflake recommends that you create proxy views and define policies to protect them within the setup script. Defining policies to protect the proxy view ensures that the definition of policies cannot be changed after the Snowflake Native App is installed. Defining policies on proxy views also ensures that during upgrades running code continues to use the policies that are applied when the upgraded version is created.

Support for external and Apache Iceberg™ tables¶

The Snowflake Native App Framework allows providers to share external tables and Apache Iceberg™ tables with consumers. The method for sharing these types of tables is similar to normal tables in that providers add views to the setup script and grant privileges on these views to an application role.

The following restrictions and requirements apply when sharing an external or Iceberg table:

• External and Iceberg tables and views that access them are read-only for the app.

• Cross-Cloud Auto-Fulfillment is not supported for apps that share external or Iceberg tables.

• Consumers must allow the app to use an external or Iceberg table in the provider account before it is available to the app.

Use caution when revoking privileges on or dropping shared objects¶

Use caution when revoking privileges from shared objects in an application package or when dropping shared objects. If an installed version of a Snowflake Native App still requires access to those objects, the Snowflake Native App might become unstable or fail.

Considerations when granting the MONITOR or OPERATE privilege on dynamic tables¶

Providers should use caution when granting the MONITOR or OPERATE privilege on dynamic tables to an application role. These privileges allow the consumer to view a dynamic table’s metadata, which might expose the implementation details of the app. See Privileges to view a dynamic table’s metadata for more information on what actions the consumer can perform.

Revoke and drop permissions on shared objects¶

Use caution when revoking permissions on shared objects from an application package or when dropping shared objects. If an installed version of the Snowflake Native App still requires access to those objects, the Snowflake Native App might become unstable or fail.