Information
The ACCOUNTADMIN system role is the most powerful role in a Snowflake account and is intended for performing initial setup and managing account-level objects. SECURITYADMIN role can trivially escalate their privileges to that of ACCOUNTADMIN Neither of these roles should be used for running Snowflake tasks. A task should be running using a custom role containing only those privileges that are necessary for successful execution of the task.
Snowflake executes tasks with the privileges of the task owner. The role that has OWNERSHIP privilege on the task owns the task.
To avoid granting a task inappropriate privileges, the OWNERSHIP privilege on the task run as owner should be assigned to a custom role containing only those privileges that are necessary for successful execution of the task.
The principle of least privilege requires that every identity, including service identities, is only given privileges that are necessary to complete its job.
If a threat actor finds a way to influence or hijack the task execution flow, they may be able to exploit privileges given to the task. In the case of an ACCOUNTADMIN or SECURITYADMIN roles, that may lead to a full account takeover. Additionally, a mistake in the task implementation coupled with excessive privileges may lead to a reliability incident, e.g. accidentally dropping database objects.
Solution
Programmatically:
In a Snowsight worksheet or through the SnowSQL CLI:
-
For each task <task_name> that runs with ACCOUNTADMIN or SECURITYADMIN privileges, create a new role <task_specific_role> and assign it to the tasks:
CREATE ROLE <task_specific_role>;GRANT OWNERSHIP ON TASK <task_name> TO ROLE <task_specific_role>;
-
After creating a new role and granting ownership of each task to it, for each task <task_name> that is owned by ACCOUNTADMIN or SECURITYADMIN roles, ensure all privileges on the tasks are revoked from the roles:
REVOKE ALL PRIVILEGES ON TASK <task_name> FROM ROLE ACCOUNTADMIN;REVOKE ALL PRIVILEGES ON TASK <task_name> FROM ROLE SECURITYADMIN;
Impact:
Existing stored procedures that are owned by the ACCOUNTADMIN or SECURITYADMIN roles and run with their privileges will need to be updated to use a task specific custom role. If that role does not have all the privileges required by the task, the task execution may fail.