Explain RBAC & Discretionary Access Control in Snowflake in Databases

54 / 66

Snowflake

RBAC & Discretionary Access Control in Snowflake

Design a secure, scalable permission model using roles and grants.

Snowflake implements Role-Based Access Control (RBAC) combined with elements of Discretionary Access Control (DAC): privileges are granted to roles, roles are granted to users (or other roles), and object owners retain discretion to grant further access on objects they own. Users never receive privileges directly — everything flows through roles, which is central to designing a maintainable permission model.

Roles are like keyrings: instead of cutting a new key for every employee for every door (users to objects directly), you hand employees a keyring (role) that already opens the doors relevant to their job, and promoting someone just means handing them an additional keyring.

Key Concepts

Roles can be hierarchical: granting one role to another creates an inheritance chain, so a higher-level role automatically includes all privileges of the roles beneath it. Snowflake ships several system-defined roles — ACCOUNTADMIN (top-level, full control), SECURITYADMIN (manages grants and users), SYSADMIN (typically the parent of custom object-owning roles), and PUBLIC (implicitly granted to every user) — which form a recommended starting hierarchy that most organizations extend with custom functional roles (e.g., ANALYST_ROLE, ETL_ROLE).

hierarchicalACCOUNTADMINSECURITYADMINSYSADMINPUBLIC

Every securable object (databases, schemas, tables, warehouses, etc.) has an owner role, and that owner has full discretion to grant privileges on the object to other roles — this is the DAC aspect layered on top of RBAC's structured hierarchy. Best practice is to avoid granting privileges to ACCOUNTADMIN for day-to-day object ownership, instead using SYSADMIN or dedicated custom roles as owners so that admin-level access isn't required for routine object management.

owner roleACCOUNTADMINSYSADMIN

Future grants (GRANT ... ON FUTURE TABLES IN SCHEMA ...) let you pre-authorize a role for objects that don't exist yet, which is essential for automated pipelines that create new tables regularly without requiring manual grant statements afterward.

GRANT ... ON FUTURE TABLES IN SCHEMA ...