@Rocky Is there grant privilege for an user with SUBMIT TASK resources. Currently in k8's we used "defaultRole: "db_admin"" so that user will all privileges but we don't want to give ad_admin role hence trying to figure is there any other ways to achieve this. thanks

In StarRocks, there is no specific "SUBMIT TASK" privilege or a standalone "TASK" object for

GRANT

statements. The ability to use

SUBMIT TASK

is generally determined by whether the user has the required privileges for the SQL statement being submitted (e.g.,

INSERT

or

CREATE TABLE AS SELECT

). To allow a user to use

SUBMIT TASK

without granting the

db_admin

role, you should grant them fine-grained privileges on the relevant databases and tables. 1. Required Privileges for

SUBMIT TASK

Because

SUBMIT TASK

is a wrapper for asynchronous execution, the user needs: * USAGE on the Catalog and Database. * SELECT on the source tables/views. * INSERT on the target table (for

SUBMIT TASK AS INSERT ...

). * CREATE TABLE on the target database (for

SUBMIT TASK AS CREATE TABLE AS SELECT ...

). 2. Example: Creating a Restricted Role Instead of

db_admin

, you can create a custom role (e.g.,

task_user

) and grant only what is necessary:

sql
-- 1. Create the role
CREATE ROLE task_user;

-- 2. Grant usage on the catalog and database
GRANT USAGE ON CATALOG default_catalog TO ROLE task_user;
GRANT USAGE ON DATABASE your_db TO ROLE task_user;

-- 3. Grant privileges for the ETL operation
-- If they are inserting into existing tables:
GRANT INSERT, SELECT ON ALL TABLES IN DATABASE your_db TO ROLE task_user;

-- If they are creating new tables:
GRANT CREATE TABLE ON DATABASE your_db TO ROLE task_user;

-- 4. Assign the role to the user
GRANT task_user TO USER 'your_user'@'%';

3. Task Management Privileges * Your Own Tasks: You can typically

ALTER TASK

,

DROP TASK

, and view your own tasks (via

INFORMATION_SCHEMA.tasks

) if you have the privileges to run the underlying statements. * Other Users' Tasks: Managing or viewing tasks created by other users often requires higher-level administrative roles like

db_admin

or specific system-level privileges such as

OPERATE

(which allows managing transactions and variables). Summary for K8s Config If you are configuring this in a Kubernetes environment (like with the StarRocks Operator), you can replace the

defaultRole: "db_admin"

with your custom role name after you have defined it and granted the necessary object-level permissions in the cluster. Note: If you are using StarRocks v3.3+ and scheduling periodic tasks, ensure the user also has

USAGE

on any resources (like

RESOURCE

objects) if the task interacts with external catalogs (e.g., Iceberg or Hive). References • administration/user_privs/authorization/privilege_item.md • sql-reference/sql-statements/account-management/GRANT.md • administration/user_privs/authorization/User_privilege.md