rbac

name	rbac
title	Snowflake RBAC Patterns
summary	Router skill for designing Snowflake Role-Based Access Control hierarchies and access role patterns.
description	Use when designing or refactoring Snowflake RBAC: choosing a role hierarchy, creating database/schema access roles, setting up functional roles, deciding between primary and secondary roles, or referencing roles in masking and row access policies. Routes to focused sub-flows for each layer of the hierarchy. Triggers: rbac, role hierarchy, access roles, functional roles, schema access role, database access role, warehouse access role, secondary roles, policy roles, role design, grant, managed access schema, future grants
tools	["snowflake_sql_execute","Read","Write","Edit","Grep","Glob"]
prompt	Help me design an RBAC hierarchy for my Snowflake account.
language	en
status	Published
author	Snowflake Solutions Team
type	community

Snowflake RBAC Patterns

Overview

This skill is a router for designing Snowflake Role-Based Access Control. It helps you pick a role hierarchy that fits your account, then routes to focused sub-flows for each layer (account roles, environment admins, domain admins, database access roles, schema access roles) and cross-cutting concerns (personas, warehouses, secondary roles, policy roles).

If you are new to RBAC, start with architecture-patterns/INSTRUCTIONS.md to decide which layers your organization actually needs. Most accounts do not need all six.

When to Use

Use this skill when you need to:

• Design a fresh RBAC hierarchy for a new Snowflake account.
• Refactor an existing role mess into a clean access-role pattern.
• Create read/write/create roles for databases or schemas.
• Decide between functional (persona) roles and data-product access roles.
• Reference roles correctly in masking or row access policies.

When NOT to Use

Delegate to bundled skills for non-RBAC concerns:

Topic	Delegate to
Multi-account strategy, org-level governance	organization-management
Cross-account data sharing via listings	internal-marketplace-org-listing
Writing masking / row access policy SQL	data-governance
Declarative sharing or application packages	declarative-sharing

This skill tells you which roles to reference. Those skills handle policy implementation and sharing mechanics.

Full Role Hierarchy

1. OOB Account Roles (ACCOUNTADMIN, SYSADMIN, USERADMIN, SECURITYADMIN)
   └── 2. Environment Admin Roles (DEV_ADMIN, PROD_ADMIN)
       └── 3. Business Domain Admins (federated / hub-spoke)
           └── 4. Data Product Admins (per team)
               └── 5. Database Access Roles (DB_R, DB_RW, DB_C)
                   └── 6. Schema Access Roles (<schema>_R, _RW, _C)

Sub-Flows

Layer / Topic	File
Pick a hierarchy	architecture-patterns/INSTRUCTIONS.md
Persona-aligned roles	personas/INSTRUCTIONS.md
OOB account roles	oob-account-roles/INSTRUCTIONS.md
Environment admin roles	environment-admin-roles/INSTRUCTIONS.md
Domain & data product admins	domain-admin-roles/INSTRUCTIONS.md
Database access roles	database-access-roles/INSTRUCTIONS.md
Schema access roles	schema-access-roles/INSTRUCTIONS.md
Warehouse access roles	warehouse-access-roles/INSTRUCTIONS.md
Secondary roles	secondary-roles/INSTRUCTIONS.md
Roles inside policies	policy-roles/INSTRUCTIONS.md

Workflow

1. Run architecture-patterns/INSTRUCTIONS.md to choose which layers apply.
2. Implement top-down: account → environment → domain → product → DB → schema.

⚠️ STOPPING POINT: After identifying which layers the user needs, confirm the plan before loading any sub-flow. Do not chain into implementation without explicit user approval.

3. For each layer, open the matching sub-flow and follow it.
4. Validate grants with SHOW GRANTS TO ROLE <name> before handing access to users.

Common Mistakes

• Granting object privileges directly to users or functional roles. Always grant to access roles first, then grant access roles to functional roles. This keeps the hierarchy refactorable.
• Skipping MANAGED ACCESS on schemas. Without it, object owners can grant access independently and bypass your hierarchy.
• Forgetting future grants. Without GRANT ... ON FUTURE plus GRANT ... ON ALL, new objects silently lose access.
• Using CURRENT_ROLE() in row access policies when secondary roles are enabled. Use IS_ROLE_IN_SESSION() so users with multiple authorized roles see the data they should. See policy-roles/INSTRUCTIONS.md.
• Creating warehouse access roles when not needed. Most accounts can grant USAGE on warehouses directly to functional roles.
• Letting ACCOUNTADMIN own objects. Object ownership should land on SYSADMIN or a domain admin, never ACCOUNTADMIN.

Stopping Points

• After Step 1 — confirm the chosen layers and implementation plan before loading any sub-flow

This router skill issues no SQL on its own. Each sub-flow that creates roles, applies grants, or alters schemas defines its own stopping points. The general rule across all sub-flows:

⚠️ STOPPING POINT: Before running any CREATE ROLE, GRANT, REVOKE, ALTER SCHEMA … ENABLE MANAGED ACCESS, or DROP ROLE statement, show the planned SQL to the user and wait for explicit confirmation. RBAC changes are easy to apply but painful to reverse once users start depending on them.