Native App Security Boundaries, Application Roles and Least-Privilege Requests

1.Provider and consumer boundaries

When a consumer installs a Native App, the setup script runs inside a new APPLICATION object in the consumer account. It creates the schemas, stored procedures, Streamlit apps and (for container apps) services that the app needs. The app owns everything it creates there. Anything outside the object belongs to the consumer, whether it existed before the install or the app created it with the consumer's permission.

The framework starts from deny. It gives the app no access to consumer data by default. The app runs under its own internal roles, which are separate from the consumer's account roles. It has full access to its own objects, but outside them it can only use objects the consumer has explicitly granted to it. It cannot read arbitrary tables, cannot move data out of the account without approval, and cannot raise its own privileges.

The isolation works in both directions. Just as the consumer's data is protected from the app, the provider's implementation, proprietary data and logic are hidden from the consumer. Each side can open the boundary for its own assets. The consumer grants the app access to the data it needs, and the provider chooses which app-owned objects to expose to users in the consumer account. Both kinds of opening happen through explicit Snowflake RBAC actions, so the question "provider boundary or consumer boundary?" comes down to who owns the asset being exposed.

The consumer's side of that opening has more than one form. Global privileges such as CREATE WAREHOUSE let the app create operational resources. Access to the consumer's own data is a separate matter and comes through references, direct object grants or database role grants. A reference is the object-level mechanism. The app declares a named slot, and the consumer binds one specific object to it. The next sections show how these fit with the manifest.

Sources12

2.Data isolation and protection across accounts

The provider and consumer are in different accounts, and the framework keeps consumer data on the consumer's side of that line. The documentation names three protections. First, consumer data does not leave Snowflake by default: the app processes it inside the consumer account, and any movement outside Snowflake, such as a call to an external API, needs a separately approved External Access Integration app specification. Second, the provider cannot query consumer data. Event and log data can go to the provider for troubleshooting only if the consumer opts in. Third, query history is redacted.

Redaction also protects the provider. Consumers cannot see objects inside the application object unless the provider grants access through application roles. For queries run during install or upgrade, queries from app-owned stored procedures, and queries that use a non-secure view or function owned by the app, Snowsight collapses the query profile into a single empty node. For install and upgrade queries, and for child jobs of app-owned procedures, query_text and error_message are blanked out of query history.

Restricting what consumers can see is allowed when it is part of the app's design. The security requirements treat cutting off consumer access to their own data as harm, but they give data masking for data access policies as a legitimate exception. These sources do not give the syntax for configuring row access or masking policies inside an app, so this lesson stops at that rule and the proxy-view guidance below.

The framework also limits the provider's shared content. Shared objects are read-only for the application object, and only the provider can update them. They are not exposed to consumers directly, only through a view that the setup script installs. Only the USAGE privilege can be granted on shared schemas, and only SELECT on shared tables and views. Tables and views that already have policies defined (row access, masking, tag based) cannot be shared. Instead, Snowflake recommends defining policies on the proxy views in the setup script, so the policies cannot be changed after install.

To keep information about the app's internals from leaking, the framework blocks some context functions. CURRENT_ROLE, CURRENT_USER and CURRENT_SESSION return null in shared content. CURRENT_IP_ADDRESS, CURRENT_AVAILABLE_ROLES and CURRENT_SECONDARY_ROLES return null there too, and throw an exception in setup scripts and in procedures and UDFs the app owns. A policy that relies on such functions can therefore behave differently in the consumer account than in the provider account.

Sources134

3.Designing application role hierarchies

Application roles are how a provider exposes chosen app capabilities to the consumer. They are created in the setup script, and they must be created inside the app. Unlike database roles, they can also hold privileges on objects outside the installed app. Every application role the setup script defines is automatically granted to the role that owns the app instance, which is the role that installed it. That owner can then grant application roles to other account roles. For example, a consumer can grant a marketing application role to its marketing team without exposing what the app built for finance.

A hierarchy is built by granting one application role to another. Then you grant each object only to the narrowest role that needs it.

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;
CREATE OR REPLACE PROCEDURE app_code.config_app(...)
GRANT USAGE ON PROCEDURE app_code.config_app(...)
  TO APPLICATION ROLE admin;

The snippet is quoted from the documentation, so the procedure arguments and body are elided as (...). In it, the user role is granted to the admin role. The example still grants admin and user USAGE on the schema explicitly, and gives only admin access to the config_app procedure. The documentation describes the result as admin having access to config_app in addition to what both roles can use.

Three limits are worth remembering. Application roles are not versioned, so dropping one or revoking a permission from an object outside a versioned schema can affect the current version or one being upgraded. They can only be safely dropped once all app versions that use them are dropped. They cannot be granted ownership of objects, so use them only to give consumers access to objects within the installed app. And by default the consumer has no privileges on objects inside the app. Even ACCOUNTADMIN cannot view them, so application roles are the only route in.

Sources51

4.Least-privilege privilege requests in the manifest

Anything the app does outside its own boundary, such as creating a warehouse or a database, needs a global privilege from the consumer. The security requirements set two rules for the manifest. It must declare every privilege the app needs on every object, plus all API integrations. And the app should request only the minimum set of privileges it needs to work. The privileges a provider can request are 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.

Some privileges reveal more than their names suggest. IMPORTED PRIVILEGES ON SNOWFLAKE DB lets the app see usage and cost information about the consumer account, so the provider should make sure consumers know this before they install. Each request carries a description that the consumer reads.

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

The requests are packaged with the installed app. After installing, the consumer runs SHOW PRIVILEGES IN APPLICATION to review them and then grants each one with a GRANT statement that targets the application itself.

These global privileges only let the app create operational resources. They do not give it access to the consumer's data. That access is a separate category and is entirely consumer-controlled, under a principle of minimum necessary access. Three mechanisms exist, from narrowest to broadest scope:

- References: the app pre-declares a named slot, such as a table with a given shape, and the consumer binds one specific object to it. References work at the level of individual named objects only. There is no database-level reference, and they do not cover objects created later. - Direct object grants: the consumer grants the app access to specific named views, tables, schemas or stored procedures. This is the most explicit and auditable approach. - Database role grants: these typically apply at database level and can cover future objects, so use them only when the app needs broad, forward-looking access.

For an app that needs a single consumer table, a reference or a grant on that one table is the least-privilege choice.

Two models of granting appear in the documentation, and they differ in who does the work. In the basic model shown above, the consumer reviews the requested global privileges and grants them manually. When the manifest sets manifest_version: 2, automated granting applies. Snowflake grants the requested privilege, for example CREATE EXTERNAL ACCESS INTEGRATION, to the app during install or upgrade. Automated granting only lets the app create the integration, share or listing. Because those objects enable external connections or data sharing, the consumer must still approve the matching app specification before they become usable. Approving requires the MANAGE APPLICATION SPECIFICATIONS privilege, which SECURITYADMIN holds by default. Owning the app is not enough.

GRANT CREATE DATABASE ON ACCOUNT TO  ?  hello_snowflake_app;

Sources4627

Exam traps

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

1. 1.Once installed, an app can read any table in the consumer account because it runs inside that account.Why is that wrong?

   The app has no access to consumer data by default. Beyond its own objects, it reaches only what the consumer explicitly grants.

   Covered in Provider and consumer boundaries

2. 2.Requesting extra privileges in the manifest, just in case, is harmless because the consumer can ignore them.Why is that wrong?

   Least privilege is a security requirement for app permissions, and the manifest must list only what the app needs.

   Covered in Least-privilege privilege requests in the manifest