Access control for Snowflake App Runtime¶

This topic describes common access control patterns for delegating operations and viewing access on Snowflake App Runtime. For the full list of privileges, see Snowflake App Runtime privileges.

Deploy to a standard database when sharing with other roles¶

Until an administrator completes account administrator setup, snow app setup resolves the destination to a personal database (USER$<login_name>). Unlike most other PDB object types, you can’t use GRANT to give other roles access to an Application Service in a personal database.

To delegate view, operate, or monitor access to other roles, deploy the Application Service to a standard database and schema. We recommend configuring the destination through account administrator setup before deploy, or explicitly in your snowflake.yml identifier.

Execution context¶

When the app queries Snowflake, each query runs under one of two identities.

• Owner’s rights: the query runs as the app’s execution role. Use this for work the app does on its own behalf.
• Caller’s rights: the query runs as the signed-in user, with that user’s default role. Use this to act on behalf of the user accessing the app.

The execution role anchors both modes. Owner’s rights queries run as the execution role directly; no secondary roles are activated. Caller’s rights queries run as the signed-in user but are bounded by the restricted caller’s rights grants on the execution role.

Where the execution role comes from depends on where the app is deployed:

• Standard database: the execution role is the role that owns the app, which is the primary role of the session that created the app.
• Personal database (PDB): the app is owned by the user who created it, not by a role, so you specify the execution role using EXECUTE_AS_ROLE in CREATE APPLICATION SERVICE. If you don’t set it, Snowflake uses the creator’s primary session role. The execution role must be granted to the owning role.

To set the execution role for a PDB app, grant the execution role to the owning role and set EXECUTE_AS_ROLE:

GRANT ROLE my_app_role TO ROLE <owning_role>;

CREATE APPLICATION SERVICE my_db.my_schema.my_app
  FROM ARTIFACT REPOSITORY my_app_repo PACKAGE web_ui
  EXECUTE_AS_ROLE = my_app_role;

For caller’s rights, grant the execution role the privileges it may use on a caller’s behalf with GRANT CALLER. Without those grants, the user can sign in but the query has no privileges to act on.

Share view-only access to a running app¶

Grant USAGE on the Application Service, plus USAGE on the database and schema that contain it, to let a role open the app. The service must be in a standard database, not a personal database. In Cortex Code CLI or Cortex Code Desktop, you can ask the agent to grant access for other roles, or use the Apps view in Desktop to manage sharing.

GRANT USAGE ON DATABASE my_db TO ROLE app_viewer;
GRANT USAGE ON SCHEMA my_db.my_schema TO ROLE app_viewer;
GRANT USAGE ON APPLICATION SERVICE my_db.my_schema.my_app TO ROLE app_viewer;

Delegate lifecycle control¶

Grant OPERATE to let a role suspend, resume, upgrade, and configure the service without transferring ownership:

GRANT OPERATE ON APPLICATION SERVICE my_db.my_schema.my_app TO ROLE app_ops;

An OPERATE role can run:

ALTER APPLICATION SERVICE my_db.my_schema.my_app SUSPEND;
ALTER APPLICATION SERVICE my_db.my_schema.my_app RESUME;
ALTER APPLICATION SERVICE my_db.my_schema.my_app UPGRADE TO VERSION LATEST;
ALTER APPLICATION SERVICE my_db.my_schema.my_app SET AUTO_SUSPEND_SECS = 900;

Delegate monitoring¶

Grant MONITOR to let a role view runtime status and read container logs:

GRANT MONITOR ON APPLICATION SERVICE my_db.my_schema.my_app TO ROLE app_monitor;

Revoke access¶

REVOKE { USAGE | MONITOR | OPERATE }
  ON APPLICATION SERVICE my_db.my_schema.my_app
  FROM ROLE <role_name>;

For general RBAC concepts, see Overview of Access Control.