Snowflake RBAC Complete Guide: Designing and Implementing Role-Based Access Control

Snowflake access control is built on RBAC (Role-Based Access Control). Every privilege is granted to a role, and users reach objects through the roles they activate. This article walks through the system-defined role hierarchy, custom role design patterns, and GRANT/REVOKE syntax in a single, structured guide.

Core Concepts of RBAC

In Snowflake RBAC, privileges are defined on objects and granted to roles. You cannot grant privileges directly to users — users always reach objects through a role. Roles can be granted to other roles to form a hierarchy, and a higher-level role inherits the privileges of every role beneath it.

Access control model:

[User] ──(USE ROLE)──→ [Role] ──(GRANT)──→ [Privilege] ──→ [Object]

* Privileges cannot be granted directly to users.
* Roles can be granted to other roles to build a hierarchy.

System-Defined Role Hierarchy

Snowflake ships with 5 system-defined roles arranged in a fixed hierarchy. Each higher-level role inherits every privilege of the roles below it.

System-defined role hierarchy:

              ACCOUNTADMIN
             /            \
      SYSADMIN        SECURITYADMIN
         │                  │
         │              USERADMIN
         │                  │
         └────── PUBLIC ────┘

ACCOUNTADMIN  : Top-level administrator for the entire account
SYSADMIN      : Manages objects such as warehouses, databases, and schemas
SECURITYADMIN : Manages roles, privileges, and GRANTs (holds MANAGE GRANTS)
USERADMIN     : Creates and manages users and roles
PUBLIC        : Lowest-level role automatically granted to every user

Responsibilities and Privileges of Each Role

Designing Custom Roles

In real-world deployments, you create custom roles that match your business requirements. Best practice is to connect custom roles under SYSADMIN.

Example custom role hierarchy:

              ACCOUNTADMIN
             /            \
      SYSADMIN        SECURITYADMIN
       /    \               │
  ETL_ADMIN  ANALYST_ADMIN  USERADMIN
     │          │            │
  ETL_ROLE   ANALYST_ROLE   PUBLIC
     │          │
  ETL_DEV    ANALYST_RO

* Every custom role is connected under SYSADMIN
  (no orphan roles).

-- Create a custom role and connect it under SYSADMIN
CREATE ROLE analyst_role
  COMMENT = 'Role for the data analytics team';

-- Connect under SYSADMIN (best practice)
GRANT ROLE analyst_role TO ROLE SYSADMIN;

-- Grant the required privileges
GRANT USAGE ON DATABASE analytics_db TO ROLE analyst_role;
GRANT USAGE ON SCHEMA analytics_db.public TO ROLE analyst_role;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_db.public TO ROLE analyst_role;
GRANT SELECT ON FUTURE TABLES IN SCHEMA analytics_db.public TO ROLE analyst_role;
GRANT USAGE ON WAREHOUSE analyst_wh TO ROLE analyst_role;

-- Grant the role to a user
GRANT ROLE analyst_role TO USER tanaka;

GRANT / REVOKE Syntax

GRANT — Granting Privileges

-- Object-level GRANTs
GRANT SELECT ON TABLE my_db.public.sales TO ROLE analyst_role;
GRANT INSERT, UPDATE ON TABLE my_db.public.reports TO ROLE etl_role;
GRANT USAGE ON WAREHOUSE etl_wh TO ROLE etl_role;
GRANT CREATE TABLE ON SCHEMA my_db.staging TO ROLE etl_role;

-- Database- and schema-level GRANTs
GRANT USAGE ON DATABASE my_db TO ROLE analyst_role;
GRANT USAGE ON ALL SCHEMAS IN DATABASE my_db TO ROLE analyst_role;

-- FUTURE GRANTs (apply to objects created later)
GRANT SELECT ON FUTURE TABLES IN SCHEMA my_db.public TO ROLE analyst_role;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE my_db TO ROLE analyst_role;

-- Role GRANTs (building the hierarchy)
GRANT ROLE analyst_role TO ROLE analyst_admin;
GRANT ROLE analyst_admin TO ROLE SYSADMIN;

REVOKE — Revoking Privileges

-- Revoke a specific privilege
REVOKE SELECT ON TABLE my_db.public.sales FROM ROLE analyst_role;

-- Revoke FUTURE GRANTs
REVOKE SELECT ON FUTURE TABLES IN SCHEMA my_db.public FROM ROLE analyst_role;

-- Remove a role from a hierarchy
REVOKE ROLE analyst_role FROM ROLE SYSADMIN;

-- CASCADE / RESTRICT (when references exist)
REVOKE SELECT ON TABLE my_db.public.sales FROM ROLE analyst_role CASCADE;

Types of Privileges

Differences Between Warehouse Privileges

Relationship with DAC (Discretionary Access Control)

Snowflake combines RBAC with Discretionary Access Control (DAC). Under DAC, the role that created an object owns it and holds every privilege on it. To transfer ownership, use GRANT OWNERSHIP ON ... TO ROLE ....

-- Transfer ownership
GRANT OWNERSHIP ON TABLE my_db.public.sales
  TO ROLE etl_role
  REVOKE CURRENT GRANTS;

-- REVOKE CURRENT GRANTS: revoke the previous owner's privileges
-- COPY CURRENT GRANTS: keep the previous owner's privileges

Best Practices

• Use ACCOUNTADMIN only for administrative work; use custom roles for day-to-day operations.
• Assign at least two users to ACCOUNTADMIN and enable MFA on each of them.
• Connect every custom role under SYSADMIN to prevent orphan roles.
• Use FUTURE GRANTs to set up privileges in advance for objects that will be created later.
• Follow the principle of least privilege — grant only what each role needs for its job.
• Assign object ownership to service roles (e.g., ETL_ROLE) so that an individual user leaving the company does not break ownership.

Key Exam Takeaways

• ACCOUNTADMIN is the top-level role that inherits both SYSADMIN and SECURITYADMIN privileges.
• SECURITYADMIN holds MANAGE GRANTS and can manage GRANTs on other roles.
• Best practice is to connect custom roles under SYSADMIN.
• The PUBLIC role is automatically granted to every user and cannot be revoked.
• FUTURE GRANTs automatically apply privileges to objects created in the future.
• On warehouses, USAGE is required to run queries while OPERATE is required to start and stop them.

Sample Question

Frequently Asked Questions