The Person Responsible
3 min read
●
Updated 27 August 2024

In Snowflake, access control operates via Discretionary Access Control (DAC) and Role-based Access Control (RBAC). Privileges are assigned to roles, which are then assigned to users and objects. We'll explore this further in the Playground section.
Hey,
Welcome and a small warning, this role part might be confusing but not if you read with focus. To ease more, the topic has been divided into 2 parts
1. Understanding(this one)
2. Playground
Let's start
Snowflake access control runs with 2 models
1. Discretionary Access Control (DAC)
2. Role-based Access Control (RBAC)
DAC says every object has an owner
RBAC says privileges to perform any action is assigned to Role and the Role is assigned to a User
Now, where are these models going to be applied on Snowflake. Let us understand the terms
- a privilege?
the level of access like OWNERSHIP, CREATE or MODIFY or MONITOR. Multiple privileges can be used at once.
- a role?
privileges are granted to roles. One role can be assigned to another role creating a role hierarchy(we'll talk later)
- an user?
a person or a program accessing Snowflake
- a securable object?
Database, Schema, Table, View, Stage, and any entity to which access can be granted. An object always has a parent object(aka container).
Now, everything revolves around this-
"A PRIVILEGE is assigned to a ROLE which is assigned to an OBJECT"
We will do the hands-on with all this, in the Playground part.
A few points to note with Object-
- A ROLE is used to create a securable object which by-default has the OWNERSHIP privilege on the object.
- In the regular schema, the owner role has all privileges on the object
- Ownership can be transferred from one role to another
- In managed access schema, only Schema owner or role with MANAGE GRANTS privileges can grant privileges on object
Some points for Roles-
- Privilege -> Role -> Object
- A user is assigned with role or multiple roles to access an object
- There are 5 System defined roles as illustrated below
3.A. On top of ACCOUNTADMIN, there is 1 more role, i.e. ORGADMIN which manages all operations at organisation level
3.B. System defined roles can't be dropped
3.C. Their privileges can't be dropped
3.D. Additional privileges can be provided to system defined roles but not recommended
ROLE HIERARCHY
4. One role can be granted to another, creating a role hierarchy and privileges are inherited by the child (Like we have System defined roles)
CUSTOM ROLE
5. We can create custom roles with USERADMIN or higher roles or if any role has CREATE ROLE privilege
6. It is recommended to have a hierarchy while creating custom roles where most role has the owner/parent as SYSADMIN
7. A ROLE can be assigned to a user only by a role with MANAGE GRANTS access or a SECURITYADMIN role
Some points to note with privileges
- Privileges are assigned with command GRANT <privilege/s> to ROLE
- To know the types of privileges, please refer https://docs.snowflake.com/en/user-guide/security-access-control-privileges.html. Trust me, it's wonderful
I hope this part wasn't that boring and we will do hands-on in the Playground part with creating ROLE, ROLE HIERARCHY, ASSIGNING ROLE and much more.
Just remember the summary
Privilege -> Role -> Object
The role is assigned to the User
Every object has an owner
Note: If you are a hackathon enthusiast, check out the Great AppSec Hackathon and participate! Open for all students worldwide.
Comments
No comments yet. Be the first to comment!