0
0
Snowflakecloud~15 mins

System-defined roles (ACCOUNTADMIN, SYSADMIN, etc.) in Snowflake - Deep Dive

Choose your learning style9 modes available
Overview - System-defined roles (ACCOUNTADMIN, SYSADMIN, etc.)
What is it?
System-defined roles in Snowflake are special user roles created by the system to manage access and permissions. These roles include ACCOUNTADMIN, SYSADMIN, SECURITYADMIN, and others. Each role has specific powers to control different parts of the Snowflake environment. They help organize who can do what in the system safely and clearly.
Why it matters
Without system-defined roles, managing who can access or change data and settings would be chaotic and risky. Mistakes or unauthorized actions could cause data loss or security breaches. These roles provide a clear, built-in way to protect the system and make sure only the right people can perform sensitive tasks.
Where it fits
Before learning about system-defined roles, you should understand basic user roles and permissions in Snowflake. After this, you can learn about custom roles and how to assign them to users for tailored access control.
Mental Model
Core Idea
System-defined roles are built-in keys that unlock specific doors in Snowflake, each controlling a different area of the system.
Think of it like...
Imagine a large office building where different employees have keys to different rooms. The system-defined roles are like master keys given to managers to open certain rooms, like the server room or HR office, ensuring only authorized people enter.
┌───────────────┐
│ ACCOUNTADMIN  │
│  (Master Key) │
├───────────────┤
│ SYSADMIN      │
│  (Manage Data)│
├───────────────┤
│ SECURITYADMIN │
│  (Manage Users│
│   & Roles)    │
├───────────────┤
│ USERADMIN     │
│  (User Control│
└───────────────┘
Build-Up - 7 Steps
1
FoundationWhat Are Roles in Snowflake
🤔
Concept: Roles define what actions a user can perform in Snowflake.
In Snowflake, a role is like a job title that comes with certain permissions. For example, a role might allow reading data, writing data, or managing users. Users are assigned roles to control what they can do.
Result
You understand that roles control access and actions in Snowflake.
Knowing that roles are the main way Snowflake controls access helps you see why system-defined roles are important.
2
FoundationIntroduction to System-Defined Roles
🤔
Concept: Snowflake provides built-in roles with predefined permissions for common administrative tasks.
Snowflake creates roles like ACCOUNTADMIN, SYSADMIN, and SECURITYADMIN automatically. These roles have powerful permissions to manage the account, data, and security. They save time and ensure best practices.
Result
You recognize system-defined roles as ready-made roles for key tasks.
Understanding these roles prevents you from creating risky or redundant roles and helps maintain security.
3
IntermediateACCOUNTADMIN Role Powers
🤔Before reading on: do you think ACCOUNTADMIN can change user passwords or only manage data? Commit to your answer.
Concept: ACCOUNTADMIN is the highest-level role with full control over the Snowflake account.
ACCOUNTADMIN can do everything: create and drop databases, manage users and roles, set account parameters, and more. It is like the system owner. Because of its power, it should be given only to trusted administrators.
Result
You know ACCOUNTADMIN controls all aspects of the Snowflake account.
Recognizing ACCOUNTADMIN as the ultimate authority helps you protect it carefully to avoid security risks.
4
IntermediateSYSADMIN Role Responsibilities
🤔Before reading on: does SYSADMIN manage users or mainly data objects? Commit to your answer.
Concept: SYSADMIN manages data objects like databases, schemas, and tables but not user security.
SYSADMIN can create, modify, and drop databases, schemas, and tables. It cannot manage users or roles. This separation helps keep data management and security management distinct.
Result
You understand SYSADMIN focuses on data management, not user control.
Knowing this separation helps design safer access policies by limiting who can change data versus who manages users.
5
IntermediateSECURITYADMIN Role Functions
🤔Before reading on: do you think SECURITYADMIN can create databases or only manage users and roles? Commit to your answer.
Concept: SECURITYADMIN manages users, roles, and grants but does not manage data objects.
SECURITYADMIN can create and manage users and roles, assign permissions, and control access. It cannot create or modify data objects like tables. This role focuses on security and access control.
Result
You see SECURITYADMIN as the gatekeeper for user and role management.
Understanding SECURITYADMIN's role helps maintain clear boundaries between security and data management.
6
AdvancedRole Hierarchy and Inheritance
🤔Before reading on: do you think roles inherit permissions from other roles automatically? Commit to your answer.
Concept: System-defined roles can be granted to other roles, creating a hierarchy that inherits permissions.
For example, SECURITYADMIN can be granted to SYSADMIN, so SYSADMIN inherits user management permissions. This lets you build layered access control where roles combine powers safely.
Result
You understand how role inheritance simplifies permission management.
Knowing inheritance helps avoid permission duplication and reduces errors in access control.
7
ExpertProtecting System-Defined Roles in Production
🤔Before reading on: do you think it's safe to assign ACCOUNTADMIN to many users for convenience? Commit to your answer.
Concept: System-defined roles are powerful and must be carefully assigned and monitored in real environments.
Best practice is to limit ACCOUNTADMIN to very few trusted users and use custom roles for daily tasks. Use role hierarchy and least privilege principles. Monitor role usage and rotate credentials regularly to prevent misuse.
Result
You know how to secure system-defined roles to protect your Snowflake account.
Understanding the risks of overusing powerful roles prevents security breaches and operational mistakes.
Under the Hood
Snowflake stores roles and their permissions in a secure metadata layer. When a user performs an action, Snowflake checks the user's active roles and their granted privileges. System-defined roles have predefined sets of privileges hardcoded by Snowflake, ensuring consistent behavior. Role inheritance is implemented by granting roles to other roles, creating a permission chain checked at runtime.
Why designed this way?
Snowflake designed system-defined roles to provide a secure, standardized way to manage access without requiring users to build complex permission sets from scratch. This reduces errors and enforces best practices. Separating duties into different roles (like ACCOUNTADMIN vs SYSADMIN) follows the principle of least privilege and helps prevent accidental or malicious misuse.
┌───────────────┐
│ User logs in  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Active Roles  │
│ (e.g. SYSADMIN│
│  + SECURITYAD)│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Permission    │
│ Check Engine  │
│ Checks if     │
│ roles allow   │
│ requested     │
│ action        │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Action Allowed│
│ or Denied     │
└───────────────┘
Myth Busters - 4 Common Misconceptions
Quick: Does ACCOUNTADMIN role automatically grant all permissions to all users? Commit to yes or no.
Common Belief:ACCOUNTADMIN role is given to all users by default to simplify access.
Tap to reveal reality
Reality:ACCOUNTADMIN is a powerful role and is NOT assigned to all users by default. It should be limited to trusted administrators only.
Why it matters:Assigning ACCOUNTADMIN widely risks accidental or malicious changes that can compromise the entire Snowflake account.
Quick: Can SYSADMIN manage user passwords? Commit to yes or no.
Common Belief:SYSADMIN can manage all aspects including user passwords and roles.
Tap to reveal reality
Reality:SYSADMIN manages data objects but cannot manage users or passwords; that is SECURITYADMIN's responsibility.
Why it matters:Confusing these roles can lead to improper access control and security gaps.
Quick: Does granting a role to a user give them only that role's permissions? Commit to yes or no.
Common Belief:Users only get permissions from the roles directly assigned to them.
Tap to reveal reality
Reality:Users also inherit permissions from roles granted to their roles, creating a hierarchy of permissions.
Why it matters:Ignoring role inheritance can cause unexpected access or denial, leading to security or operational issues.
Quick: Is it safe to share ACCOUNTADMIN credentials among team members? Commit to yes or no.
Common Belief:Sharing ACCOUNTADMIN credentials is fine as long as the team trusts each other.
Tap to reveal reality
Reality:Sharing credentials is unsafe; each user should have their own login with appropriate roles to track actions and maintain security.
Why it matters:Shared credentials prevent accountability and increase risk of unauthorized or untraceable changes.
Expert Zone
1
System-defined roles have some privileges that cannot be revoked or altered, ensuring core system integrity.
2
Role inheritance can create complex permission chains that are hard to audit without proper tools.
3
ACCOUNTADMIN can grant itself any role or privilege, so losing control of this role means losing control of the entire account.
When NOT to use
Avoid using system-defined roles for everyday tasks or application users. Instead, create custom roles with only the necessary permissions. Use system-defined roles only for administration and security management to minimize risk.
Production Patterns
In production, organizations assign ACCOUNTADMIN to a very limited number of senior admins. SYSADMIN handles database and schema management. SECURITYADMIN manages users and roles. Custom roles are created for developers and analysts with least privilege. Role inheritance is used to combine permissions cleanly.
Connections
Role-Based Access Control (RBAC)
System-defined roles are a specific implementation of RBAC in Snowflake.
Understanding system-defined roles deepens comprehension of RBAC principles used widely in security systems.
Least Privilege Principle
System-defined roles embody the least privilege principle by separating duties into distinct roles.
Knowing how these roles enforce least privilege helps design safer access policies in any system.
Organizational Hierarchies
Role inheritance in Snowflake mirrors organizational hierarchies where managers inherit responsibilities from their teams.
Seeing this connection helps grasp how permissions flow and why clear role design matters.
Common Pitfalls
#1Assigning ACCOUNTADMIN role to many users for convenience.
Wrong approach:GRANT ROLE ACCOUNTADMIN TO USER analyst1;
Correct approach:GRANT ROLE SYSADMIN TO USER analyst1;
Root cause:Misunderstanding the power of ACCOUNTADMIN and ignoring the principle of least privilege.
#2Confusing SYSADMIN and SECURITYADMIN roles and mixing their responsibilities.
Wrong approach:GRANT ROLE SYSADMIN TO USER security_officer; -- expecting user to manage roles
Correct approach:GRANT ROLE SECURITYADMIN TO USER security_officer;
Root cause:Not knowing the distinct purposes of system-defined roles.
#3Ignoring role inheritance and assigning redundant permissions.
Wrong approach:GRANT SELECT ON DATABASE sales TO ROLE analyst; GRANT ROLE SYSADMIN TO ROLE analyst;
Correct approach:GRANT ROLE SYSADMIN TO ROLE analyst; -- SYSADMIN already has SELECT privileges
Root cause:Lack of understanding of how role inheritance simplifies permission management.
Key Takeaways
System-defined roles in Snowflake are built-in roles with predefined permissions to manage different parts of the system securely.
ACCOUNTADMIN is the most powerful role and should be tightly controlled to protect the entire Snowflake account.
SYSADMIN manages data objects, SECURITYADMIN manages users and roles, keeping duties separate for security.
Role inheritance allows combining permissions safely and reduces complexity in access management.
Proper use and protection of system-defined roles are essential to maintain security and operational stability in Snowflake.