Managing access with inherited grants¶

To opt in to this public preview, after you enable preview features for your account, use the ALTER ACCOUNT command. For example:

ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED';

What are inherited grants?¶

An inherited grant is a single grant created on a container object (ACCOUNT, DATABASE, or SCHEMA) that automatically applies to every current and future object of a specified type within that container. Inherited grants are created with the INHERITED keyword in the standard GRANT statement.

Container ownership alone does not authorize the creation of inherited grants.

Why use inherited grants¶

An inherited grant covers existing and future objects, without future-grant limitation, and without drift over time as the container’s contents evolve.

• Ease of use: Express container-wide intent with one statement. A single GRANT INHERITED <privilege> ON ALL <object_type> IN <container> replaces multiple grants for existing and new objects. Adding a new object to a container, such as a new table in a database, requires no follow-up grant administration.
• Reduce grant proliferation and simplify role hierarchy: One inherited grant takes the place of many individual records. Inherited grants allow access to be managed at the container level instead of using object-specific roles. This simplifies the grant catalog and the role hierarchy complexity, making role-based access easier to reason about during reviews.
• Consistent authorization profile: Because the privilege is defined once at the container level, every object of the specified type receives identical access. This eliminates drift between objects that may otherwise accumulate when grants are issued one object at a time.
• Application access at scale: Snowflake Native Apps can be granted broad read access to a container with one inherited grant per object type.
• Auditability: Inherited grants are recorded at the container level, which makes container-wide access reviewable from a single row. New columns on SHOW GRANTS and the GRANTS_TO_ROLES view (IS_INHERITED, INHERITED_FROM, INHERITED_FROM_DATABASE, INHERITED_FROM_SCHEMA) let auditors trace any per-object access back to the inherited grant that authorized it.

How inherited grants work¶

An inherited grant is indicated by the keyword INHERITED and has four parts:

Example:

GRANT INHERITED SELECT ON ALL TABLES
  IN SCHEMA prod.analytics
  TO ROLE analyst_role;

This statement creates an inherited grant for tables in the prod.analytics schema.

Snowflake applies the inherited grant to matching existing tables in the schema. Snowflake also applies the same privilege to matching tables created later in the schema.

When to use inherited grants¶

Inherited grants are designed for the standard case where a role should have a uniform privilege across every current and future object of a given type in a container. They are not the right choice for every scenario.

Use inherited grants when¶

• You want a role to have a uniform privilege across all objects of a type in a container. For example, an analyst role that should be able to SELECT from every table in a database. This is the canonical use case.
• You want new objects to be automatically covered without administrative action. Inherited grants eliminate the need to maintain future grants or to backfill grants when a new object is created.
• You manage grants at the container level rather than the object level. If your access model is “this role gets read access to this database,” inherited grants express that intent in a single statement.
• You are granting access to a Snowflake-managed application (for example, a governance scanner) that needs to see every current and future object in a container.
• You are operating at scale. Customers with large numbers of grants benefit from the reduction in grant records, which improves authorization performance.

Use granular grants when¶

• A subset of objects in the container needs different access. If some tables in a database hold sensitive PII and should not be readable by the role, an inherited grant covering “all tables” is the wrong tool. Use granular grants on the sensitive tables, or use row access policies and masking policies to control access at the row or column level.
• Different objects in the container need different privileges. If some tables should be SELECT-only and others should be INSERT-able, model the difference with granular grants on the appropriate objects rather than overgranting via inheritance.
• The privilege should not extend to future objects. Inherited grants always cover future objects of the specified type. If you want to grant a privilege on the objects that exist today and explicitly require a review step before new objects are added, use GRANT ... ON ALL <objects> IN <container> (the existing one-time bulk grant).
• You are granting on object types not supported by inherited grants (see Limitations in this topic).

The following table summarizes the guidance on when to use inherited vs. granular grants:

Security considerations¶

Future objects receive access automatically¶

An inherited grant applies to matching objects created later. A broad database-level grant can give a role access to future objects that do not exist when the grant is created.

Use caution with executable objects¶

Some Snowflake objects can execute with the privileges of the object owner rather than only the privileges of the caller. For example, owner’s-rights stored procedures run with the privileges of the procedure owner.

Inherited grants do not change object ownership. However, an inherited grant can grant a privilege such as USAGE or EXECUTE on current and future executable objects. This can allow a role to invoke objects that run with the owner’s privileges.

Review inherited grants carefully for executable object types, such as procedures, functions, tasks, alerts, services, and Streamlit in Snowflake apps.

Before granting inherited execution access, verify that:

• The role should be allowed to invoke every matching current and future object in the scope.
• The object type’s execution model is understood.
• Owner-executed objects do not expose privileges beyond the intended operation.

Use least privilege¶

Use the narrowest practical scope for inherited grants. Prefer schema-level and database-level inherited grants when access requirements differ by data domain or object type.

Stricter authorization for ownership transfer of owner-executed objects¶

GRANT OWNERSHIP on an owner-executed object to a role outside your active role hierarchy now fails with an authorization error. Previously the statement succeeded. The change prevents privilege escalation: with inherited grants, a role can retain USAGE on an object it has transferred away, which would let it execute the object’s body under the new owner’s privileges.

The change only applies to ownership transfers of owner-executed objects, that is, objects whose body or schedule runs with the new owner’s privileges:

The following remain unchanged:

• GRANT OWNERSHIP on objects that are not owner-executed (tables, schemas, databases, sequences, stages, and so on).
• GRANT OWNERSHIP ... COPY CURRENT GRANTS, which has always required account-level MANAGE GRANTS or that the receiver role be in the caller’s role hierarchy.
• Account-level MANAGE GRANTS (held by SECURITYADMIN) continues to authorize ownership transfer to any role.

To transfer ownership of an owner-executed object, the caller must either:

• Have the receiver role in their active role hierarchy (that is, the receiver role has been granted, directly or transitively, to the role they are using), or
• Hold account-level MANAGE GRANTS.

Container-level MANAGE GRANTS (held on a database or schema) does not authorize the transfer.

Limitations¶

Privileges that cannot be granted as inherited grants¶

The following privileges are not eligible for inheritance:

• OWNERSHIP.
• Privileges whose only target is the account (for example, CREATE WAREHOUSE, MANAGE WAREHOUSES, MONITOR USAGE). Inherited grants flow from a container to objects inside the container, so privileges that have no enclosing container cannot be inherited.
• USAGE on ROLE and USAGE on USER.

Object types that cannot be targets of an inherited grant¶

GRANT INHERITED <privilege> ON <type> IN <container> is rejected when <type> is one of:

• ORGANIZATION
• APPLICATION (consumer-side installed app)
• APPLICATION PACKAGE
• SHARE
• INTEGRATION

Account scope excludes native apps and bundles¶

GRANT INHERITED <privilege> ON ALL <type> IN ACCOUNT does not flow into objects that live inside an APPLICATION (consumer-side) or APPLICATION PACKAGE (provider-side) container.

Data sharing and the Native App Framework¶

Inherited grants are not compatible with cross-account sharing boundaries. The following are rejected:

• Granting inherited privileges on an imported (shared) database or any schema or object inside one.
• Granting inherited privileges on objects that belong to a foreign account.
• Granting inherited privileges to a database role from an imported database, or to a database role that has already been shared with a consumer.
• Granting a database role that holds inherited grants to a share.
• Granting inherited privileges to an APPLICATION ROLE.
• Granting inherited privileges on an APPLICATION PACKAGE or on a consumer-side APPLICATION object (covered by the unsupported object types list above).

Restricted clauses¶

Inherited grants cannot be combined with WITH GRANT OPTION, CASCADE, or RESTRICT.

Next Topics:

• Using inherited grants