Use owner’s rights and restricted caller’s rights in an app¶

About owners right’s and restricted caller’s rights in an app¶

Within a Snowflake Native App, executables run with either owner’s rights or restricted caller’s rights. In the context of the Snowflake Native App Framework, the following types of executables are supported:

• Stored procedures owned by the app

• Services available in apps with containers

Owner’s rights:

Executables that use owner’s rights run with the privileges granted to the owner of the executable. By default, executables within an app use owner’s rights. In an app, the owner of the executable is the app itself.

For example, the CREATE PROCEDURE command creates a stored procedure that uses owner’s rights by default. Consumers can call the stored procedure if they have been granted access using application roles. If the app has the privileges to perform a task, then the stored procedure can perform that operation.

For information on owner’s rights, see Understanding caller’s rights and owner’s rights stored procedures.

Caller’s rights:

Executables that use caller’s rights run with the privileges granted to the caller. However, for security reasons, the Snowflake Native App Framework does not support executables with caller’s rights.

Restricted caller’s rights:

Restricted caller’s rights allow an executable to run with caller’s rights, but restrict which of the caller’s privileges the executable runs with. With restricted caller’s rights, an executable owned by an app cannot run with a specific privilege unless an administrator in the consumer account explicitly allows it by using the GRANT CALLER command.

For brevity, executables that run with restricted caller’s rights are also known as RCR executables.

For general information on restricted caller’s rights, see Restricted caller’s rights.

Determine the access requirements of an app¶

The Snowflake Native App Framework gives providers flexibility in how they configure access to the data and executables managed by the app. The following table provides guidelines for which mechanism to use depending on the access requirements of the app:

Add the restricted_callers_rights property to the manifest¶

As a provider, if you include an RCR executable in an app, Snowflake recommends that you add the restricted_callers_rights to the manifest file as shown in the following example:

restricted_callers_rights:
  enabled: true
  description: This app includes stored procedure that uses restricted caller's rights.

Although restricted_callers_rights is not required, if it is present and enabled is set to true, Snowsight includes a section named Restricted caller’s rights in the app’s listing.

Configure a procedure or service to use restricted caller’s rights¶

To create a stored procedure that uses restricted caller’s rights, use the EXECUTE AS RESTRICTED CALLER clause as shown in the following example:

CREATE OR REPLACE PROCEDURE CORE.HELLO()
RETURNS STRING
LANGUAGE SQL
EXECUTE AS RESTRICTED CALLER
AS
BEGIN
  RETURN 'Hello Snowflake!';
END;

For more information, see CREATE PROCEDURE.

Using a restricted caller’s rights service in an app¶

For more information on configuring a service to use restricted caller’s rights, see Connecting to Snowflake from inside a container using caller’s rights.

In an app, a Snowpark Container Services service can run with privileges of the app (owner’s rights) or with the privileges of the caller of the service (restricted caller’s rights). However, the service owner role is the app instead of the service user role. When granting caller grants, a consumer specifies the app by using the TO APPLICATION clause as shown in the following example:

GRANT CALLER USAGE ON DATABASE consumer_db TO APPLICATION hello_snowflake_app;

This example allows the service to run with restricted caller’s rights to use the caller’s role to access the consumer_db database.

Limitations on restricted caller’s rights in an app¶

The following limitations apply when using restricted caller’s rights within an app.

Calling billing functions from a restricted caller’s rights procedure in an app¶

Billing functions such as SYSTEM$CREATE_BILLING_EVENT or SYSTEM$CREATE_BILLING_EVENTS cannot be called from an RCR executable. To call these functions from an RCR executable in an app, include these functions in an owner’s rights procedure and call the procedure from the restricted caller’s rights procedure.

Intellectual property protection and restricted caller’s rights¶

Apps that include owner’s rights stored procedures redact information about the internal implementation of the app. For more information, see Protect provider intellectual property.

Stored procedures with restricted caller’s rights also redact internal information about the app. This is particularly true for the following commands, views, and functions where much of the information is redacted:

• The DESCRIBE PROCEDURE command

• The PROCEDURES view of the Information Schema

• The PROCEDURES view of the Account Information Schema

• The GET_DDL function

However, unlike stored procedures with owner’s rights, procedures using restricted caller’s rights do not redact information from the query history and query profiles.

Developing apps that use restricted caller’s rights¶

In general, only roles that have been granted the MANAGE CALLER GRANTS privilege can grant caller grants to an executable. However, during the development lifecycle of a Snowflake Native App, providers may need to create and drop the app frequently. The Snowflake Native App Framework provides a mechanism for creating caller grants for an app in development mode.

Providers can use a role without the MANAGE CALLER GRANTS to grant caller grants to an app. However, this requires all of the following:

• The app must be created in development mode.

• The current role has the app owner role in the role hierarchy.

• The app owner role has a superset of the caller grants that are being granted.

  Note

  The ALL CALLER PRIVILEGES privilege is a superset of any set of caller privileges.

The superset requirement cannot be met through INHERITED CALLER grants, which normally cover all current and future objects of a particular type under a specific container. For more information, see GRANT CALLER.

To meet this requirement, the caller grants being granted must be explicitly covered by the caller grants that are granted to the app owner role.

GRANT ALL INHERITED CALLER PRIVILEGES
  ON ALL DATABASES IN ACCOUNT
  TO ROLE app_dev_role;