System roles within snowflake

Within Snowflake, there are many different roles that restrict which privileges a user has. Roles are assigned to users depending on their business requirements. A user can have one or multiple roles that they can switch between depending on what actions they are taking. Snowflake has a hierarchy of roles, where the privileges of each role are inherited by all roles above it.

There are two main types of roles within Snowflake: system-defined roles and custom roles. System defined roles are related to account management whereas custom roles are organization specific. Whilst it is possible to grant additional privileges to system-defined roles this is not best practice. If a user requires additional privileges it is generally best to grant them a custom role alongside any system-defined roles. This keeps their account management and organization-specific roles separate.

System Defined Roles

Figure 1: Role Hierarchy (Overview of Access Control — Snowflake Documentation)

Custom Roles

Custom roles are any roles that are not included in the above system-defined roles. They can be created by the SECURITYADMIN roles as well as any other role with the create role privilege. It is good practice to create a hierarchy of custom roles with the SYSADMIN being given the role at the top of the hierarchy. This allows the SYSADMIN to manage all warehouses, databases and objects whilst restricting management of users and roles to the SECURITYADMIN and ACCOUNTADMIN roles. If SYSADMIN is not given the top hierarchy role the system administrator will not be able to manage objects owned by these custom roles. This is counterproductive as the SYSADMIN role is generally in charge of all objects.

For more information about this topic visit the Snowflake documentation. Overview of Access Control — Snowflake Documentation