Delegating grant management with container-level MANAGE GRANTS¶

This topic provides an introduction to container-level MANAGE GRANTS for databases and schemas.

ALTER ACCOUNT SET FEATURE_RBAC_INHERITED_GRANTS = 'ENABLED';

What are container-level MANAGE GRANTS?¶

The MANAGE GRANTS privilege allows a role to manage access on securable objects using direct grants and inherited grants. A role with account-level MANAGE GRANTS can manage privileges broadly across the account.

MANAGE GRANTS on databases and schemas are container-level MANAGE GRANTS that provide a more scoped way to delegate grant management. The role that holds MANAGE GRANTS on a container can manage all grant types on objects inside that container (including the container itself) and only that container. This enables a least-privilege delegation model where database and schema administrators define future, inherited, and bulk grants on the containers they own without involving SECURITYADMIN or ACCOUNTADMIN.

Why use container-level MANAGE GRANTS¶

• Enable database and schema administrators to define direct and inherited grants on objects they manage.
• Build a least-privilege grant administration model that meets your organizational needs.
• Limit granting the account-level MANAGE GRANTS privilege and reduce risk.

How container-level MANAGE GRANTS works¶

A role that holds container-level MANAGE GRANTS is a role granted MANAGE GRANTS on a specific container. Within that container, it can do everything a holder of MANAGE GRANTS ON ACCOUNT can do today, but it cannot affect grants on objects outside the container. Specifically, a role that holds container-level MANAGE GRANTS can:

• Resolve any securable inside the container in a grant-management call (for example, SHOW / GRANT / DESCRIBE call like SHOW TABLES will show all tables inside the container).
• Grant or revoke direct and inherited grants on objects inside the container.
• Grant MANAGE GRANTS on lower-level containers inside the container (for example, on schemas inside its database), if the role holds MANAGE GRANTS WITH GRANT OPTION.

A role that holds container-level MANAGE GRANTS cannot delegate MANAGE GRANTS on the same container, or on container object types inside the same container, to another role unless it holds MANAGE GRANTS WITH GRANT OPTION on that container.

Comparison with account-level MANAGE GRANTS¶

Security considerations¶

MANAGE GRANTS is a powerful privilege. Grant it only to roles that are trusted to administer access within the specified scope of authority.

Use the narrowest practical scope of authority¶

Prefer schema-level MANAGE GRANTS when access administration should be limited to one schema.

GRANT MANAGE GRANTS ON SCHEMA prod.finance
  TO ROLE finance_access_admin;

Use database-level MANAGE GRANTS only when the role should manage grants across the database.

GRANT MANAGE GRANTS ON DATABASE prod
  TO ROLE prod_access_admin;

Use account-level MANAGE GRANTS only when account-wide grant management is required.

Container-level MANAGE GRANTS can expand access¶

A role with container-level MANAGE GRANTS can grant privileges to other roles within its scope of authority.

For example, a role with MANAGE GRANTS ON SCHEMA prod.finance can grant access to supported objects in prod.finance. Depending on the privileges granted, this can expose data, allow object execution, or delegate access more broadly than intended.

Treat container-level MANAGE GRANTS as delegated access administration, not as a low-risk privilege.

Use caution with executable objects¶

Container-level MANAGE GRANTS can allow an administrator to grant execution privileges, such as USAGE or EXECUTE, on supported executable objects in the container.

Some Snowflake objects can execute with the privileges of the object owner rather than only the privileges of the caller. Before allowing a container-level grant administrator to manage execution access, verify that the administrator is trusted to decide who can invoke all supported executable objects in the container.

Review executable object types such as procedures, functions, tasks, alerts, services, Streamlit in Snowflake apps, and notebooks.

MANAGE GRANTS does not grant object access by itself¶

MANAGE GRANTS allows grant management. It does not by itself allow the role to query data, create objects, modify objects, execute objects, or use warehouses.

However, a role with MANAGE GRANTS can grant privileges within its scope of authority.

Audit container-level MANAGE GRANTS regularly¶

Regularly review roles that have MANAGE GRANTS at the account, database, and schema levels.

SHOW GRANTS TO ROLE finance_access_admin;
SHOW GRANTS ON DATABASE prod;
SHOW GRANTS ON SCHEMA prod.finance;

Pay special attention to container-level MANAGE GRANTS on sensitive databases and schemas that contain executable objects.

Limitations¶

• Container ownership does not imply MANAGE GRANTS: Owning a database or schema does not authorize a role to administer grants on it; the owner must also be granted MANAGE GRANTS on the container.
• Self-grant restriction: A role that holds container-level MANAGE GRANTS cannot regrant MANAGE GRANTS on the same container unless the role holds WITH GRANT OPTION. It can always grant MANAGE GRANTS on a lower-level container inside its scope of authority.
• Cascade behavior: Cascade revocation of MANAGE GRANTS only removes dependent MANAGE GRANTS, not the other grants those roles created.

Next Topics:

• Using container-level MANAGE GRANTS