Use owner’s rights and restricted caller’s rights in an app¶
This topic describes how to configure an app to use owner’s rights and restricted caller’s rights.
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:
Access required |
How to get access |
---|---|
Data or functions owned by the app |
Use owner’s rights by default. Providers do not need to request access from the consumer to create or access objects owned by the app. |
Specific tables, views, or functions in the consumer account |
Request references from the consumer |
Tables, views, functions, and row policies owned by another user or role. |
Use restricted caller’s rights, which allow the consumer to enable access to these objects. |
Broad access to consumer-owned databases |
Use database role grants |
Queries that access a combination of consumer and provider data |
Use references and owner’s rights together |
Account-level objects |
Provide custom scripts that contain GRANT commands to grant privileges on specific objects. |
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.
General limitations on restricted caller’s rights¶
For general limitations on restricted caller’s rights on executables, see Limitations of an executable with restricted caller’s rights. The limitations listed there also apply to apps.
Additional limitations for apps¶
In addition to the general limitations on restricted caller’s rights, apps have the following limitations:
Unrestricted caller’s rights are not supported for executables in an app.
Cannot execute the following commands:
SHOW ROLES
SHOW USERS
SHOW [CALLER] GRANTS
SHOW AVAILABLE LISTINGS
Cannot execute the following functions:
ALL_USER_NAMES
GET_USERS_FOR_COLLABORATION
CURRENT_IP_ADDRESS
CURRENT_AVAILABLE_ROLES
CURRENT_SECONDARY_ROLES
SYSTEM$ALLOWLIST (or the deprecated SYSTEM$WHITELIST)
Persistent reference functions are not supported.
Relative paths to objects on a stage are not supported.
RCR executables cannot access the app’s internal objects.
Executables with owner’s rights cannot call other executables that use unrestricted caller’s rights.
Although executables with owner’s rights owned by the application can invoke RCR executables, the RCR executables must also be owned by the app. For example, an app’s stored procedure with owner’s rights cannot call a consumer’s stored procedure with restricted caller’s rights.
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.
Enable app developers to grant caller rights to an app in dev mode¶
To allow an app owner role to grant a certain set of caller grants to an app in development mode, a user with the ACCOUNTADMIN role or a role that has been granted the MANAGE CALLER GRANTS privilege must first grant caller grants that cover the set of grants to the app owner role.
The following example shows how to grant the required caller privileges on the databases in an account:
GRANT ALL INHERITED CALLER PRIVILEGES
ON ALL DATABASES IN ACCOUNT
TO ROLE app_dev_role;
This command grants all caller grants on all databases to the app_dev_role
role.
Note
This command only grants caller grants. It does not allow the app developer to access an object that they are not already allowed to access.
Additional security measures for apps in development mode¶
Allowing app developers owner roles without the MANAGE CALLER GRANTS privilege streamlines the app development process, but it also introduces potential security risks. To minimize these risks, Snowflake verifies that the app owner continues to have required caller grants for the app. If the app owner loses the required caller grants, the app loses them also.