Feature policies¶

A feature policy controls which object types can be created in a given context. You can apply a feature policy to all native apps in an account, to a specific native app, or to all personal databases in an account.

Feature policies are schema-level objects. Before creating one, create a dedicated database and schema to store it.

For details on using feature policies with native apps, see Use feature policies to limit the objects an app can create.

For details on using feature policies with personal databases, see Use feature policies with personal databases.

Blockable object types¶

Account-level objects (native apps only)¶

When a native app is installed with automated granting of privileges, the app can receive privileges that let it create account-level objects such as warehouses, compute pools, and databases. Once granted, these privileges can’t be directly revoked by the consumer. A feature policy lets administrators prevent apps from exercising those privileges to create specific object types, without revoking the underlying privilege.

The following account-level object types can be blocked:

• COMPUTE_POOLS
• DATABASES
• WAREHOUSES

Other blockable types¶

The following object types can be blocked in any context to which the policy is attached, whether that is native apps or personal databases:

• AGENTS
• APPLICATION_SERVICE
• ARTIFACT_REPOSITORY
• GIT_REPOSITORY
• MCP_SERVERS
• SCHEMA
• SECRET
• TASKS
• WORKSPACE

Privileges required to use feature policies¶

Create a feature policy¶

Use the CREATE FEATURE POLICY command to create a feature policy. The following example creates a policy that blocks task creation:

CREATE DATABASE feature_policy_db;
CREATE SCHEMA sch;
CREATE FEATURE POLICY feature_policy_db.sch.block_create_task_policy
  BLOCKED_OBJECT_TYPES_FOR_CREATION = (TASKS);

You can also create a policy that doesn’t restrict any object types. This is useful for overriding a more general account-level policy on a specific app:

CREATE FEATURE POLICY feature_policy_db.sch.block_nothing_policy
  BLOCKED_OBJECT_TYPES_FOR_CREATION = ();

Apply a feature policy¶

To all native apps¶

To apply a feature policy to all native apps in the account, use the ALTER ACCOUNT command:

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

To replace an existing account-level policy without unsetting it first, use FORCE:

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

To unapply the policy from all native apps:

ALTER ACCOUNT UNSET FEATURE POLICY FOR ALL APPLICATIONS;

To a specific application¶

To apply a feature policy when installing an application, use the WITH FEATURE POLICY clause of the CREATE APPLICATION command:

CREATE APPLICATION hello_snowflake_app
  WITH FEATURE POLICY = feature_policy_db.sch.block_create_db_policy;

To apply a feature policy to an existing application, use the ALTER APPLICATION command:

ALTER APPLICATION hello_snowflake_app
  SET FEATURE POLICY feature_policy_db.sch.block_create_db_policy;

To unapply the policy from a specific application:

ALTER APPLICATION hello_snowflake_app UNSET FEATURE POLICY;

A per-application policy overrides the account-level FOR ALL APPLICATIONS policy for that application. See Feature policy precedence for details.

To all personal databases¶

To apply a feature policy to all personal databases in the account, use the ALTER ACCOUNT command with ON ALL PERSONAL DATABASES:

ALTER ACCOUNT
  SET FEATURE POLICY feature_policy_db.sch.block_app_services_policy
  ON ALL PERSONAL DATABASES;

To unapply the policy from all personal databases:

ALTER ACCOUNT UNSET FEATURE POLICY ON ALL PERSONAL DATABASES;

Feature policy precedence¶

Feature policies can be applied at the account level (covering all apps or all personal databases) or at the object level (a specific app). The most specific policy takes effect:

Account:

Feature policies applied to an account are the most general. The FOR ALL APPLICATIONS policy applies to every app unless a per-app policy overrides it. The ON ALL PERSONAL DATABASES policy applies to every personal database; there is no per-database override for personal databases.

Object:

A feature policy applied to a specific application overrides the account-level FOR ALL APPLICATIONS policy for that application.

For example, an account-level policy can block database creation for all apps. A specific app can then have a separate policy with no restrictions, allowing that app to create databases while the restriction still applies to all other apps.

Delete a feature policy¶

Use the DROP FEATURE POLICY command:

DROP FEATURE POLICY feature_policy_db.sch.block_create_task_policy;

A feature policy can’t be dropped if it’s currently applied to an object. Unapply it first using ALTER ACCOUNT or ALTER APPLICATION, then drop it.

View feature policies¶

To list the feature policies in the account that you have access to:

SHOW FEATURE POLICIES ON ACCOUNT;

To list the feature policies applied to a specific application:

SHOW FEATURE POLICIES ON APPLICATION hello_snowflake_app;

To view the details of a specific feature policy:

DESCRIBE FEATURE POLICY feature_policy_db.sch.block_create_task_policy;

Identify feature policy references¶

The POLICY_REFERENCES Information Schema table function can identify feature policy references. There are two different syntax options:

1. Return a row for each object that has the specified feature policy assigned to it:

   Copy code

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
       policy_kind,
       ref_entity_name,
       ref_entity_domain,
       policy_status
   FROM TABLE(information_schema.policy_references(policy_name => 'feature_policy_db.sch.block_create_task_policy'));
   

2. Return each feature policy assigned to the account:

   Copy code

   USE DATABASE my_db;
   USE SCHEMA information_schema;
   SELECT policy_name,
       policy_kind,
       ref_entity_name,
       ref_entity_domain,
       policy_status
   FROM TABLE(information_schema.policy_references(ref_entity_name => 'my_account', ref_entity_domain => 'account'));
   

Replication considerations¶

Feature policy references at the account level are replicated when the database containing the policy is included in the replication group, for example by setting ALLOWED_DATABASES = feature_policy_db.

If the account has already been replicated to a target account, do the following:

1. Update the replication or failover group in the source account to include the databases and object types required to replicate the feature policy.
2. Execute a refresh operation to update the target account.

If you don’t include the policy database in the replication group, Snowflake creates a dangling reference in the target account. The fully-qualified policy name points to the source account’s database, which doesn’t exist in the target account, so the policy isn’t enforced there.

For more information, see Replication considerations.