The Person Responsible

3 min read

Updated 27 August 2024

blog banner

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).

Securable Objects in Snowflake

 

Now, everything revolves around this-

"A PRIVILEGE is assigned to a ROLE which is assigned to an OBJECT"

Privilege

We will do the hands-on with all this, in the Playground part.

 

A few points to note with Object-

 

  1. A ROLE is used to create a securable object which by-default has the OWNERSHIP privilege on the object.
  2. In the regular schema, the owner role has all privileges on the object
  3. Ownership can be transferred from one role to another
  4. In managed access schema, only Schema owner or role with MANAGE GRANTS privileges can grant privileges on object

 

Some points for Roles-

 

  1. Privilege -> Role -> Object
  2. A user is assigned with role or multiple roles to access an object
  3. There are 5 System defined roles as illustrated below

 

No alt text provided for this image

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

 

  1. Privileges are assigned with command GRANT <privilege/s> to ROLE
  2. 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

 

No alt text provided for this image

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!

user
The Person Responsible | Where U Elevate