Snowflake Roles & Access Control: A Detailed Deep Dive

Modern data platforms are only as secure as the rules governing who can access what. As organizations scale their data operations, onboarding more teams, integrating more systems, and storing increasingly sensitive information, the question of who can see and do what becomes mission-critical.

Snowflake was built with this challenge in mind. This guide breaks down Snowflake's access control framework from the ground up, covering the underlying models, built-in roles, best practices, and hands-on examples to help you build a secure, scalable permission structure for your team.

Snowflake's Access Control Framework

Snowflake controls access to data using a combination of three access control approaches.

Discretionary Access Control (DAC)

Every securable object (table, database, schema, warehouse, etc.) has an owner. The owner can grant privileges on that object to other roles.

Ownership includes full control over the object, including the ability to transfer ownership.

Example: If you create a table, the role used to create it becomes the owner and can grant SELECT or other privileges.

Role-Based Access Control (RBAC)

RBAC is the primary model Snowflake operates on. The structure is straightforward:

• Privileges are granted to roles

• Roles are assigned to users

• Users activate roles to perform actions

Structure

Privileges → Roles → Users

This model makes access management scalable, organized, auditable, and well-suited for enterprise governance. You manage access through roles rather than per-user, which dramatically simplifies oversight at scale.

Recommended Read: A Practical Guide to Zero-Copy Cloning in Snowflake

User-Based Access Control (UBAC)

Privileges can also be granted directly to users. However, these privileges are applied only when secondary roles are enabled for the session.

Snowflake recommends using RBAC rather than direct user grants because role-based models are easier to manage, audit, and scale.

Key Terms to Know

Before diving into configuration, it helps to have a clear grasp of the core terminology.

1. Securable Object: Any object (database, schema, table, warehouse, stage, etc.) whose access can be controlled. Access must be explicitly granted unless inherited through role hierarchy.

   
   

2. Role: A collection of privileges that can be assigned to users or other roles.

   
   

3. Privilege: A specific permission, such as SELECT, INSERT, CREATE, or USAGE.

   
   

4. User: A person or service identity that authenticates into Snowflake and activates roles to perform operations.

System-Defined Roles

Snowflake provides built-in system roles:

• ACCOUNTADMIN

• SYSADMIN

• SECURITYADMIN

• USERADMIN

• PUBLIC

These roles:

• Cannot be deleted

• Have predefined privilege scopes

• Serve administrative and governance functions

They form the foundation of Snowflake’s access control hierarchy.

Source: Snowflake role hierarchy and privilege inheritance

Account Administration Best Practices

When a Snowflake account is created, one user is initially granted the ACCOUNTADMIN role.

Recommended Practices

• Assign at least one additional ACCOUNTADMIN user

• Do not use ACCOUNTADMIN as a daily default role

• Use SYSADMIN as the default for routine operations

• Enable MFA for administrative users

• Configure user contact information

Example

GRANT ROLE ACCOUNTADMIN, SYSADMIN TO USER user2;

ALTER USER user2

SET EMAIL='user2@domain.com',

DEFAULT_ROLE=SYSADMIN;

Creating Custom Roles (Least Privilege Approach)

Snowflake strongly recommends following the Principle of Least Privilege: users should receive only the permissions required for their specific tasks. Avoid assigning high-level system roles for routine work, and instead create business-specific roles aligned to actual responsibilities.

The workflow for creating a custom role follows three steps: create the role, grant the necessary privileges, and assign it to a user.

Example: A Role With Single-Table Query Access

Suppose you want a role that can query only one table — d1.s1.t1.

Step 1: Create the role

CREATE ROLE r1
  COMMENT = 'Limited query access role';

Only roles with the CREATE ROLE privilege (such as USERADMIN) can create roles.

Step 2: Grant the required privileges

To query a table, a role needs:

• USAGE on warehouse

• USAGE on database

• USAGE on schema

• SELECT on table

GRANT USAGE ON WAREHOUSE w1 TO ROLE r1;
GRANT USAGE ON DATABASE d1 TO ROLE r1;
GRANT USAGE ON SCHEMA d1.s1 TO ROLE r1;
GRANT SELECT ON TABLE d1.s1.t1 TO ROLE r1;

The USAGE privileges are not optional. Without them, even a correctly granted SELECT will fail because Snowflake requires access at each level of the hierarchy , warehouse compute, database namespace, schema container, and then the object itself.

Step 3: Assign the role to a user

GRANT ROLE r1 TO USER smith;

User Smith can now activate role r1.

Set Default Role

ALTER USER smith

SET DEFAULT_ROLE = r1;

Creating a Read-Only Role

A common use case is granting a team or service read access to all tables within a schema without allowing any modifications. Here's how to set that up:

CREATE ROLE read_only;

GRANT USAGE ON DATABASE d1 TO ROLE read_only;
GRANT USAGE ON SCHEMA d1.s1 TO ROLE read_only;
GRANT SELECT ON ALL TABLES IN SCHEMA d1.s1 TO ROLE read_only;
GRANT USAGE ON WAREHOUSE w1 TO ROLE read_only;

This role can SELECT data but cannot INSERT, UPDATE, DELETE, CREATE, or DROP any objects. It's a clean, safe pattern for analysts, reporting tools, or third-party integrations that only need to read data.

Why Snowflake's RBAC Model Is Powerful

Snowflake’s access control design provides:

• Scalable permission management

• Clear separation of duties

• Reduced configuration errors

• Centralized privilege administration

• Strong governance and auditing capabilities

Instead of managing permissions user-by-user, administrators manage access through roles, which simplifies oversight and improves security posture.

Work With Snowflake Experts Who've Seen It All

Designing a clean role hierarchy is straightforward when you're starting fresh. In practice, most teams are working with inherited environments, legacy grants, and access patterns that have quietly accumulated over the years, and untangling that while keeping production running is a different problem entirely.

That's where Claroda comes in. As a specialist Snowflake consultancy, we help data teams design, implement, and optimize their Snowflake environments — including access control frameworks that are secure, auditable, and built to scale with your organization.

Whether you need a full governance review or just a second pair of expert eyes on your role hierarchy, book a consultation with Claroda and get it done right.