RBAC, DAC, and the Securable Object Hierarchy
1. RBAC, DAC, and the Securable Object Hierarchy
Hello and welcome to Snowflake Management, Governance and Collaboration. This is our second course in the SnowPro Core track. In this video, we're looking at how Snowflake controls who can access what — starting with Role-Based Access Control, Discretionary Access Control, and the securable object hierarchy.2. Introducing Claro
Throughout this course we'll work with Claro, a global credit-building app managing sensitive financial data across multiple regions in Snowflake.3. The Access Problem
Claro's account holds credit scores, repayment histories, and personal financial records. Left unmanaged, any analyst with a login could query all of it. Snowflake manages access using a combination of Role-Based Access Control and Discretionary Access Control.4. The Building Blocks
Four terms underpin Snowflake's security model. A privilege is permission to act: SELECT lets you read, INSERT lets you write, CREATE lets you build. An object is anything a privilege can be granted on -- a table, schema, database, or warehouse. A role is an entity that holds privileges -- you can grant a role to a user, or to another role to build a hierarchy. A user is the person or service account that connects to Snowflake and holds roles.5. Role-Based Access Control (RBAC): How It Works
Role-based access control is the foundation for managing access in Snowflake. You grant privileges on objects to a role, and assign the role to users. SELECT on credit scores goes to the analyst role, and the analyst role goes to Maria. When a new analyst joins Claro, you assign the role. When they leave, you revoke it. The role handles it all.6. Implementing RBAC
The first statement grants SELECT access on the Claro credit scores table to the analyst role. The second assigns that role to Maria. These are two distinct steps: privileges are granted to roles, and roles are assigned to users. Note that SELECT on the table alone isn't enough. The role also needs USAGE on the schema and the database above it. We'll cover that in a moment.7. Discretionary Access Control (DAC)
Every object in Snowflake has an owner, always a role, not a person. The owner decides who else gets access. Ownership can be transferred using GRANT OWNERSHIP. Role based access control defines the role structure. DAC determines what each role controls within it. Together they give you a complete access model.8. Transferring Ownership
Claro's credit scores table needs to move from SYSADMIN to the data_engineer role. GRANT OWNERSHIP specifies the table and the role taking over. The critical detail is REVOKE CURRENT GRANTS at the end. Without it, the previous owner's grants persist alongside the new ownership. Adding it makes the transfer clean.9. The Securable Object Hierarchy
Every object in Snowflake lives in a hierarchy: Organization, Account, Databases, Schemas, then the objects themselves. To query a table, SELECT alone isn't enough, you also need USAGE on the schema and USAGE on the database. Every level must be explicitly granted. Miss one and the query fails.10. Applying USAGE at Every Level
Three grants are required to give the analyst role access to Claro's credit scores table: USAGE on the database, USAGE on the schema, and SELECT on the table. The most common mistake is granting SELECT and forgetting the USAGE grants above. The hierarchy enforces that every level of access is deliberate.11. System-Defined Roles
ACCOUNTADMIN sits at the top of the role hierarchy -- it inherits everything from every other system role, so reserve it for account-level administration, never day-to-day work. SYSADMIN creates databases and warehouses. SECURITYADMIN owns network policies, masking policies, and role management -- and also inherits USERADMIN's privileges, so it can create and manage users too. USERADMIN creates users and assigns roles. PUBLIC is the default role every user gets automatically and should never hold sensitive privileges.12. Let's practice!
Let’s put your knowledge to the test.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.