Native App Logic, Containers, Data Sharing and Distribution

1.Application logic: procedures, UDFs and external functions

A Native App can include stored procedures, user-defined functions and external functions, written in any language Snowflake supports. Snowpark libraries are supported for procedures in Java, Scala and Python. Every one of these objects is defined in the app's setup script. Python code must use a supported runtime, because Native Apps don't support decommissioned Python versions. That limit applies to new versions and to installing existing ones.

The key security fact is how the code runs. Every procedure and UDF runs as the application itself and can reach every object in the installed app. That is why every procedure must be EXECUTE AS OWNER. A caller's-rights procedure would let a consumer write code that reads or changes the app's internals and its shared data. Because the code runs with this much access, Snowflake recommends bound parameters for any SQL built from user input, including procedure arguments, to prevent SQL injection.

Code can also live in files. Referenced files, such as JARs and Python modules, belong to a specific version and are imported by procedures and UDFs. Resource files, such as a machine learning model, go on a named stage the package can read. Any procedure, UDF or external function that imports these files must be created in a versioned schema, and the import path starts with / and is relative to the version root, the directory that holds the manifest.

CREATE FUNCTION app_code.add(x INTEGER, y INTEGER)
  RETURNS INTEGER
  LANGUAGE JAVA
  HANDLER = 'TestAddFunc.add'
  IMPORTS = ('/JARs/Java/TestAddFunc.jar');

Sources1

2.User interfaces: Streamlit or a container endpoint

An app can include a Streamlit app as its user interface. The manifest names which one opens by default with default_streamlit under artifacts, giving the schema-qualified Streamlit object. Context functions behave differently inside a Streamlit app in a Native App. For example, CURRENT_USER returns NULL unless the app has been granted READ SESSION ON ACCOUNT.

artifacts:
  ...
  default_streamlit: app_schema.streamlit_app_na
  ...

An app with containers uses Snowpark Container Services. Its manifest lists each container image under artifacts.container_services.images, as /<database>/<schema>/<image_repository>/<image_name>:tag, with one entry per image. Instead of a Streamlit UI, it can set default_web_endpoint with a service and an endpoint. That endpoint must also be defined in the service specification file. An app can set only one of these two defaults.

Two privileges are specific to apps with containers. CREATE COMPUTE POOL lets the app create a compute pool in the consumer account, and it isn't needed if the consumer creates the pool manually. BIND SERVICE ENDPOINT is needed for an endpoint to be reachable from outside Snowflake. The provided documentation doesn't describe the compute pool's own settings, such as sizing. Remember the earlier rule as well: Snowpark Container Services objects can't go in a versioned schema, so they belong in a regular schema.

artifacts:
  readme: readme.md
  setup_script: setup.sql
  container_services:
    images:
      - /dev_db/dev_schema/dev_repo/image1
      - /dev_db/dev_schema/dev_repo/image2
  default_web_endpoint:
    service: ux_schema.ux_service
    endpoint: ui
privileges:
 - CREATE COMPUTE POOL:

Sources231

3.Bundling provider data and keeping boundaries

The application package carries data content as well as logic, so the provider has to decide which data ships with the app. Objects that the setup script creates stay private to the app. Provider data reaches the app only when it is shared through the package. When you share an object this way, you must also share the schema that contains it. Views can be shared the same way.

Data that lives outside the application package can't be shared with the installed app directly. Instead, the provider grants REFERENCE_USAGE on the outside database to the package's share. Next, they create a view inside the package that selects from the outside table, and then grant USAGE on the view's schema and SELECT on the view to the share. Only the view crosses the boundary, not the underlying database.

GRANT REFERENCE_USAGE ON DATABASE other_db
  TO SHARE IN APPLICATION PACKAGE app_pkg;

Shared data also changes how policies behave. In shared content, several context functions return null, including CURRENT_ROLE, CURRENT_USER and CURRENT_WAREHOUSE. A row access policy that relies on them won't work as it does in the provider's own account. Even when it does run, a username like CURRENT_USER's can exist in more than one account.

Sources41

4.References to consumer objects and external dependencies

The opposite case is an app that needs a consumer's existing object, such as a table in one of their databases. A plain grant isn't enough, because the app can't know the schema and object names in the consumer account ahead of time. References solve this: the consumer names the object and allows access to it.

On the provider side, there are three steps. First, decide which objects need references and which privileges they need. Then define the references in the manifest file. Finally, add a stored procedure to the setup script that handles the callback for each reference. The consumer side runs in a fixed order after installation, as the check below tests.

A related dependency rule goes the other way. A setup script shouldn't create objects outside the app that point to objects inside it. For example, a view in an outside database that reads an app table breaks when the consumer drops the app. This applies to tables, procedures, UDFs and references.

Sources56

5.Distribution modes and separate dev and production packages

The DISTRIBUTION property controls the kinds of listing a package can back. INTERNAL allows only private listings inside the organization that created the package, and it skips the automated security scan. EXTERNAL allows listings outside that organization, including private listings to other organizations, public listings and Marketplace listings. You can set the property when you create the package or change it later. If it is set at creation, every version or patch added afterwards is scanned immediately. In Snowsight, the same choice appears as distributing to accounts outside or inside your organization.

Snowflake's recommended setup uses two packages. A development package set to INTERNAL lets developers iterate quickly without starting a security review on every change. A production package set to EXTERNAL receives only versions that have passed the provider's own review, and it goes to Snowflake for scanning and to external consumers. This keeps experimental work away from the version that paying consumers run.

A separate package setting, MULTIPLE_INSTANCES = TRUE, lets a consumer install up to 30 instances of an app. Once it is set, it can't be turned off.

CREATE APPLICATION PACKAGE hello_snowflake_package
  DISTRIBUTION =  ? ;

Sources789

Exam traps

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

1. 1.Procedures in a Native App can use caller's rights so that they respect the consumer user's own privileges.Why is that wrong?

   Every procedure the app creates or runs must be EXECUTE AS OWNER, and it runs as the application with access to all of the app's objects.

   Covered in Application logic: procedures, UDFs and external functions

2. 2.A container app can declare both a default Streamlit app and a default web endpoint and let the consumer pick.Why is that wrong?

   The manifest accepts only one of default_web_endpoint and default_streamlit.

   Covered in User interfaces: Streamlit or a container endpoint

3. 3.Every version and patch is security-scanned, even in a package used only inside the organization.Why is that wrong?

   The automated scan doesn't run when DISTRIBUTION is INTERNAL. That is why the development package uses INTERNAL.

   Covered in Distribution modes and separate dev and production packages