Account Access and Security
Privileges, roles, and hierarchy
Snowflake applies discretionary access control on top of role-based access control. A privilege (USAGE, SELECT, INSERT, CREATE TABLE, OWNERSHIP…) is granted on a securable object (database, schema, table, warehouse) to a role; roles are granted to users and to other roles. Effective rights are the union of privileges held by the active role and every role beneath it in the hierarchy.
The built-in chain is ACCOUNTADMIN → SECURITYADMIN → USERADMIN, with SYSADMIN owning warehouses and databases and PUBLIC granted to every user. Best practice: build custom functional roles (e.g. ANALYST_RO), grant object privileges to them, then grant those roles up to SYSADMIN; keep user and role administration in SECURITYADMIN/USERADMIN.
Traps
- Ownership carries every privilege including the right to grant, so it is usually the answer to "who can grant access?".
- In a managed access schema, object owners cannot grant; the schema owner or a role with MANAGE GRANTS must.
- Without
GRANT ... ON FUTURE TABLES IN SCHEMA, newly created tables are invisible to a role. - A role must be active (or the user's default role) before its privileges apply.
Other controls
Network policies (IP allow/block lists), MFA, federated SAML SSO, key-pair and OAuth for service users, and masking/row access policies for column- and row-level protection.
Rule of thumb
When access "should work" but doesn't, walk the chain: privilege on the object → granted to a role → that role granted into the user's active role hierarchy → role actually active.