Native App Privileges: Application Roles, Manifest Requests, References and Consumer Governance

1.Application roles: exposing what the app owns

Inside the consumer account, everything the setup script creates belongs to the app. Consumers reach those objects through application roles. The provider creates the roles in the setup script, nests them into a hierarchy, and grants privileges on app objects to them. Unlike database roles, application roles can also be granted privileges on objects outside the installed app. The role itself, though, must always be created inside the app.

CREATE APPLICATION ROLE admin;
CREATE APPLICATION ROLE user;
GRANT APPLICATION ROLE user TO APPLICATION ROLE admin;

CREATE OR ALTER VERSIONED SCHEMA app_code;
GRANT USAGE ON SCHEMA app_code TO APPLICATION ROLE admin;
GRANT USAGE ON SCHEMA app_code TO APPLICATION ROLE user;

At install time, the role that installs the app becomes its owner. Every application role defined in the setup script is automatically granted to that owning role. From there, the app owner can pass the access on to other account roles in the consumer account. So the provider decides the shape of the access (which roles exist and what each one can touch), and the consumer decides which of their people get each role. The framework gives you CREATE, ALTER, DROP, GRANT, REVOKE and SHOW commands for application roles.

Sources1

2.Requesting global privileges through the manifest

Application roles cover objects the app owns. Some apps also need to act at the account level, for example creating a warehouse or running tasks. In that case the consumer has to grant the privilege. The provider works out which privileges the app needs and lists them under privileges in the manifest file. The consumer then reviews those requests after installation and grants them.

privileges:
  - EXECUTE TASK:
    description: "Privilege to run tasks within the consumer account"

These are the global privileges a provider can request: BIND SERVICE ENDPOINT, CREATE COMPUTE POOL, CREATE DATABASE, CREATE WAREHOUSE, EXECUTE ALERT, EXECUTE TASK, EXECUTE MANAGED TASK, IMPORTED PRIVILEGES ON SNOWFLAKE DB, MANAGE WAREHOUSES and READ SESSION. The requests travel with the installed app. The consumer lists them with SHOW PRIVILEGES IN APPLICATION hello_snowflake_app; and grants each one with an ordinary GRANT whose grantee is the application, such as GRANT CREATE DATABASE ON ACCOUNT TO APPLICATION hello_snowflake_app;.

IMPORTED PRIVILEGES needs special care. When a consumer grants IMPORTED PRIVILEGES ON SNOWFLAKE DB, the app can see the usage and cost information for the consumer account, so providers should make sure consumers know this before they publish. The same grant syntax gives the app imported privileges on any other database the consumer chooses.

GRANT IMPORTED PRIVILEGES ON DATABASE MYDATABASE TO  ?  hello_snowflake_app;

Sources2

3.References: scoped access to named objects in the consumer account

Global privileges are too broad when an app only needs one particular consumer table. A plain object grant doesn't solve the problem either, because the app cannot determine the name of the schema and object in the consumer account. References solve it. The consumer names the object and binds it to a reference that the provider defined in the manifest. The app gets exactly the privileges the reference lists on that one object, and nothing else in the account.

references:
  - consumer_table:
      label: "Consumer table"
      description: "A table in the consumer account that exists outside the APPLICATION object."
      privileges:
        - INSERT
        - SELECT
      object_type: TABLE
      multi_valued: false
      register_callback: config.register_single_reference

Secure patterns across the provider and consumer accounts. The provider's code and the consumer's data live in different accounts, so each side controls only its own half of every access path. Pick the mechanism by what the app needs:

- Data or functions the app owns: owner's rights by default. The provider doesn't need to ask the consumer for anything. - Specific tables, views or functions in the consumer account: request references from the consumer. The consumer picks the exact object, so the app never needs to know or guess its name. - Queries that combine consumer and provider data: use references and owner's rights together. - Account-level operations such as creating databases or executing tasks: restricted caller's rights, which the consumer enables explicitly.

References are also a versioning contract. If a later version removes a reference definition that code still uses, consumers get an error when they call that code after upgrading. Snowflake recommends against removing a reference definition from the manifest in a new version. If you must remove one, update the code that uses it in the same release and tell consumers in the README. Across accounts, anything that leaves the consumer account, such as external endpoints or data sharing with other accounts, is not a reference. It goes through app specifications, which the consumer approves or declines.

The privilege-granting workflow. For global privileges, the sequence is fixed. The provider determines the privileges the app needs. The provider adds them to the manifest file. After installing, the consumer reviews the requested privileges and then grants them to the application. References follow the same shape (the provider declares, the consumer reviews and binds), with SYSTEM$REFERENCE and the callback in place of a plain GRANT. Because the app should request only the minimum privileges it needs, and must tell consumers what it requires before asking for grants, treat the manifest as the provider's disclosure and the consumer's review as the approval gate.

SHOW PRIVILEGES IN APPLICATION hello_snowflake_app;

Sources3425

4.Consumer-side governance: feature policies and app specifications

With automated granting of privileges, an app can request EXECUTE TASK, EXECUTE MANAGED TASK, CREATE WAREHOUSE, CREATE COMPUTE POOL, BIND SERVICE ENDPOINT, CREATE DATABASE and CREATE EXTERNAL ACCESS INTEGRATION. Once the app is installed, the consumer can't revoke those privileges directly. Consumer administrators can still limit what the app creates, by using feature policies. A feature policy blocks object types, such as warehouses or compute pools, and it can target one app or every app in the account.

ALTER ACCOUNT
  SET FEATURE POLICY feature_policy_db.sch.block_create_db_policy
  FOR ALL APPLICATIONS;

To scope a policy to one app, use CREATE APPLICATION ... WITH FEATURE POLICY or ALTER APPLICATION ... SET FEATURE POLICY. To check what applies, run SHOW FEATURE POLICIES ON APPLICATION. Apply policies carefully: if you block an object type the app needs for installation or upgrade, the app may stop working properly.

Feature policies can't block external access integrations. That kind of outbound access is governed by app specifications. With app specifications, consumers review and approve or decline requests for external endpoint connections, third-party authentication, data sharing with other Snowflake accounts, inter-app connections and restricted operations. Consumers can decline these requests or approve only part of one, so the app has to handle unapproved specifications gracefully. Providers can also register a specification_action lifecycle callback that reacts when a specification is approved or declined.

Sources67

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.A consumer who regrets an automatically granted privilege like CREATE WAREHOUSE can simply revoke it from the app.Why is that wrong?

   Automatically granted privileges can't be revoked directly after installation. The consumer has to use a feature policy, at app level or for all applications, to block the object type. Blocking something the app needs can break installation or upgrade.

   Covered in Consumer-side governance: feature policies and app specifications

2. 2.IMPORTED PRIVILEGES ON SNOWFLAKE DB is a harmless metadata grant that needs no disclosure to consumers.Why is that wrong?

   It lets the app see the consumer account's usage and cost information, and providers should make sure consumers know this.

   Covered in Requesting global privileges through the manifest

3. 3.A provider can safely drop an unused-looking reference definition from the manifest in a new version.Why is that wrong?

   Code that still uses the removed reference fails for consumers after they upgrade. Update the dependent code in the same release and notify consumers.

   Covered in References: scoped access to named objects in the consumer account