Roles and Access Control

Analogy categoryAnalogies

Role-Based Access Control (RBAC) Fundamentals

Snowflake uses role-based access control: privileges on objects (databases, schemas, tables, warehouses) are granted to roles, and roles are granted to users, rather than granting privileges directly to individual users. A user can be granted multiple roles and switch between them within a session using USE ROLE, and because privileges flow through roles, revoking a person's access company-wide is as simple as revoking role membership rather than hunting down dozens of individual object grants.

🏏

Cricket analogy: It's like a franchise team issuing role-specific access badges — 'bowling coach', 'physio' — rather than naming each staff member individually on every locker room door.

The Default Role Hierarchy

Snowflake ships with a built-in hierarchy: ACCOUNTADMIN sits at the top and encompasses SECURITYADMIN (manages users, roles, and grants) and SYSADMIN (typically owns warehouses, databases, and other objects created by teams), while PUBLIC is automatically granted to every user as the default, least-privileged role. Custom roles should generally be created under SYSADMIN in the hierarchy so that SYSADMIN retains the ability to manage all objects, and best practice is to avoid using ACCOUNTADMIN for day-to-day work, reserving it for account-level administration only.

🏏

Cricket analogy: It's like a cricket board where the BCCI president (ACCOUNTADMIN) oversees both the selection committee (SECURITYADMIN) and the operations team running grounds and fixtures (SYSADMIN), with every fan holding a basic membership (PUBLIC).

sql

-- Create a custom role under SYSADMIN
USE ROLE SECURITYADMIN;
CREATE ROLE data_analyst;
GRANT ROLE data_analyst TO ROLE SYSADMIN;

-- Grant object privileges to the custom role
GRANT USAGE ON DATABASE sales_db TO ROLE data_analyst;
GRANT USAGE ON SCHEMA sales_db.public TO ROLE data_analyst;
GRANT SELECT ON ALL TABLES IN SCHEMA sales_db.public TO ROLE data_analyst;

-- Assign the role to a user
GRANT ROLE data_analyst TO USER priya_k;

-- The user switches into the role for a session
USE ROLE data_analyst;

Future Grants and Ownership

Manually granting SELECT on every existing table doesn't cover tables created tomorrow, so Snowflake supports future grants — GRANT SELECT ON FUTURE TABLES IN SCHEMA ... TO ROLE ... — which automatically apply the specified privilege to any matching object created after the grant is issued. Ownership (the OWNERSHIP privilege) is distinct from other privileges: it's the only privilege that can be transferred between roles, it's required to drop or fully alter an object, and by default the role that creates an object becomes its owner, which is why teams typically have a dedicated role create shared objects rather than individual users.

🏏

Cricket analogy: Future grants are like a standing accreditation policy that automatically covers any player added to the squad roster mid-season, not just the current 15 named players.

Use GRANT ... TO ROLE PUBLIC sparingly — PUBLIC is implicitly held by every user in the account, so anything granted there is visible account-wide, effectively bypassing the principle of least privilege that RBAC is designed to enforce.

Objects created while a user is under their personal default role (rather than a shared team role) are owned by that individual role, which can strand access if the person leaves the company and their role is dropped. Always create shared production objects using a dedicated functional role, not an individual's personal role.

Snowflake grants privileges to roles, and roles to users, rather than granting privileges directly to individuals.
ACCOUNTADMIN sits atop SECURITYADMIN and SYSADMIN; PUBLIC is the default role every user implicitly holds.
Custom roles should be created under SYSADMIN in the hierarchy so SYSADMIN retains manageability of all objects.
Future grants (GRANT ... ON FUTURE ...) automatically apply privileges to objects created after the grant.
OWNERSHIP is the only transferable privilege and is required to drop or fully alter an object.
By default the role that creates an object becomes its owner, so shared objects should be created via functional roles.
Avoid using ACCOUNTADMIN for daily work and avoid over-granting to PUBLIC, which applies account-wide.