Skip to main content

Setup Snowflake Role Based Access for Success

Snowflake Role Based Access (RBAC) allows you to manage permissions efficiently by assigning access based on roles and responsibilities rather than individual users. This hierarchical model simplifies access management, enhances security, and ensures that users and system-controlled processes operate with the least privilege necessary.. Snowflake does a fantastic job of explaining what is RBAC.

In this article, I cover a basic RBAC that is based on the primary activity for which users or system controlled processes operate.

Snowflake Role Based Access

Standard Snowflake Role Based Access Roles

Snowflake provides several predefined roles that serve as the foundation for access control. These roles are structured in a hierarchy, each with specific administrative and operational privileges. By default, when you sign up for Snowflake, you are given an “ACCOUNTADMIN” role, which is the highest level for managing the Snowflake account.

1. ORGADMIN (Organization Administrator)

  • The highest-level role, responsible for managing Snowflake accounts within an organization.
  • Can create, modify, and delete accounts.
  • Has access to billing and account-level settings across multiple accounts.

2. ACCOUNTADMIN (Account Administrator)

  • The most powerful role within a single Snowflake account.
  • Can create and manage all objects, users, and roles within the account.
  • Typically used for initial account setup and rarely granted to day-to-day users.

3. SECURITYADMIN (Security Administrator)

  • Manages users, roles, and role-based permissions.
  • Controls access to objects but does not have full control over the account like ACCOUNTADMIN.
  • Ideal for ensuring least privilege access policies.

4. SYSADMIN (System Administrator)

  • Responsible for creating and managing databases, schemas, and warehouses.
  • Can assign ownership of objects to other roles.
  • Typically used by data engineers and database administrators.

5. PUBLIC

  • Provides minimal access, typically limited to public datasets or metadata.
  • The default role assigned to all users.

Changing your Role

In Snowflake, it is very common for 1 user to have multiple roles, in particular when it comes to the owners and administrators of Snowflake:

Which role to use as the owner and administrator of Snowflake?

We recommend assigning SYSADMIN as the default role for all admins. When account or organizational administration is needed, you can change the role.

RoleACCOUNTADMINSYSADMIN
PurposeHighest-level role for managing the Snowflake accountManages system objects like databases, schemas, and warehouses
ScopeFull control over the entire Snowflake account, including billing and security settingsControl over database, schema, and warehouse creation but no direct account-wide permissions
Primary Responsibilities– Managing account-wide settings (e.g., billing, governance)
– Creating and managing users and roles
– Overseeing security and access control
– Assigning the SYSADMIN role
– Creating and managing databases and schemas
– Managing warehouses and compute resources
– Assigning ownership of database objects to other roles
Should Own Databases & Schemas?No (Best practice: Delegate to SYSADMIN)Yes (Recommended owner of databases, schemas, and warehouses)
Should Be Used Day-to-Day?❌ No – Reserved for administrative and governance tasks✅ Yes – Commonly used for managing data infrastructure

Adding Functional Roles

Beyond standard roles, functional roles can be created to align access with specific business functions, workloads, or governance models. These roles help in segregating responsibilities while maintaining security and manageability.

In Snowflake you can add, assign and visualize your roles from the Users & Roles tab. Adding a role is as simple as clicking “+ Role”

LOADING – Responsible for loading data into Snowflake. Typically we create a dedicated STAGE schema to hold data that we load from data pipelines or 3rd party ETL applications.

REPORTING – Provides read access to analytical tables and views for business intelligence and reporting users.

REPORTING_ELEVATED – Read access with additional permissions, such as the ability to create views or temporary tables.

Assign Roles to Users

Within the users tab you can view and assign roles. Typically, a SECURITYADMIN or higher role is required to manage user-role assignments.

Permissions to Databases, Schema, Tables

Snowflake’s permission model supports granular access control at multiple levels:

  • Database-level permissions – Control access to an entire database.
  • Schema-level permissions – Define permissions for schemas within a database.
  • Table/view-level permissions – Control access to specific tables or views.

Future Grants in Snowflake

When you apply privileges to a database, schema or table, you are able to set permissions to future objects that are created. Snowflake has an ever expanding collection of permissions as new features are added. When granting “future” permissions, it will not automatically grant permissions to existing objects. For example if you have tables and stages and you want to give access to a role, you will need to manually grant the role.

To save time and manual work and confusion, it is important to carefully review and setup your roles and database permissions according to the first phase and use cases.

Least Privilege Access

We implement RBAC using the principle of least privilege, ensuring:

  • Early-stage administrators should be given access to Snowflake SYSADMIN role as the default role, which ensures creation of database objects, schemas and tables occur with the correct role.
  • Users have only the access they require, reducing security risks.

Schemas and Roles Aligned to Business Function, Billing, and Governance

We typically apply future permissions at the Schema level. For example, we typically use “Loading” exclusively for loading data into a STAGE schema so all of our stage data from external systems are isolated and centralized. For governance and ease of management it we know that LOADING is generally pumping data into STAGE schemas.

Design Result – At the end of the month, our cost and overhead of loading data into Snowflake can be measured with the LOADING role, and the size / overhead of that data is also easy to manage.

DB, Schema, Table Ownership

This is a question we often get. What role should own the database, schema, and table. Historically we created a DBA role that served as a single, elevated permission with control over the entire Snowflake database. As time progressed and requirements for automated 3rd party tools needing to create assets in Snowflake we ultimately elevated permissions to a role above “LOADING” granting the ability to create views, tables, and stored procedures as needed.