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).
-- 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.
Practice what you learned
1. In Snowflake's RBAC model, what do privileges get granted to directly?
2. Which built-in role is responsible for managing users, roles, and grants?
3. What does GRANT SELECT ON FUTURE TABLES IN SCHEMA ... TO ROLE ... accomplish?
4. What makes the OWNERSHIP privilege different from other privileges like SELECT or USAGE?
5. Why is it best practice to create shared production objects using a functional role rather than an individual's personal role?
Was this page helpful?
You May Also Like
Secure Data Sharing
How Snowflake lets one account share live, read-only data with another account instantly, without copying or moving any data between them.
Masking Policies and Row Access Policies
How Snowflake dynamically hides sensitive column values or entire rows from unauthorized roles, enforced consistently at query time across every downstream consumer.
Zero-Copy Cloning
How Snowflake's CLONE command creates instant, storage-free copies of tables, schemas, and databases by referencing existing micro-partitions rather than duplicating data.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics