http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> If resource group is already exists...
# questions-and-troubleshooting
u
@Rocky If resource group is already exists, how can I set new user to using resource group
r
To assign a new user to an existing resource group, you need to add a new classifier to that resource group using the 
ALTER RESOURCE GROUP
statement. Syntax
Copy code
sql
ALTER RESOURCE GROUP <group_name> ADD (user='<user_name>');
Examples * Assign a single user:
Copy code
sql
    ALTER RESOURCE GROUP my_group ADD (user='alice');
* Assign a user with specific conditions (e.g., only for 
SELECT
queries):
Copy code
sql
    ALTER RESOURCE GROUP my_group ADD (user='bob', query_type in ('select'));
Important Notes 1. Multiple Classifiers: A resource group can have multiple classifiers. When a user runs a query, StarRocks matches the query to the best-fitting classifier to determine which resource group to use. 2. Verification: You can check the current classifiers and their IDs for a resource group by running:
Copy code
sql
    SHOW RESOURCE GROUP <group_name>;
3. Roles: You can also assign entire roles to a resource group instead of individual users:
Copy code
sql
    ALTER RESOURCE GROUP my_group ADD (role='analyst_role');
References • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md
To assign a new user to an existing resource group, you use the 
ALTER RESOURCE GROUP
statement to add a new classifier. Syntax
Copy code
sql
ALTER RESOURCE GROUP <group_name> ADD (user='<user_name>');
Examples * Add a specific user:
Copy code
sql
    ALTER RESOURCE GROUP my_group ADD (user='alice');
* Add a user with additional conditions (e.g., only for 
SELECT
queries):
Copy code
sql
    ALTER RESOURCE GROUP my_group ADD (user='bob', query_type in ('select'));
* Add a role instead of a user:
Copy code
sql
    ALTER RESOURCE GROUP my_group ADD (role='analyst');
Key Details • Classifiers: A resource group can have multiple classifiers. When a user runs a query, StarRocks matches the query against these classifiers to determine which resource group to use. • Viewing Current Users: To see which users/classifiers are already assigned to a group, run:
Copy code
sql
  SHOW RESOURCE GROUP <group_name>;
• Privileges: This operation requires the 
ALTER
privilege on the target resource group. References • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md
To set a new user to use an existing resource group, you have two primary methods depending on whether you want the assignment to be automatic or manual. 1. Automatic Assignment (Classifiers) This is the recommended method. You add a classifier to the existing resource group. Whenever that user logs in and runs a query, StarRocks will automatically assign them to that group. Syntax:
Copy code
sql
ALTER RESOURCE GROUP <group_name> ADD (user='<user_name>');
Example:
Copy code
sql
-- Adds user 'jack' to the resource group 'production_rg'
ALTER RESOURCE GROUP production_rg ADD (user='jack');
2. Manual Session Assignment If you want a user to manually switch to a specific resource group for their current session, they can use a session variable. This overrides the automatic classifier matching. Syntax:
Copy code
sql
SET resource_group = '<group_name>';
Example:
Copy code
sql
-- The current user switches to 'analytics_rg' for this session
SET resource_group = 'analytics_rg';
3. Verify the Assignment To see which users or classifiers are currently assigned to a resource group, use:
Copy code
sql
SHOW RESOURCE GROUP <group_name>;
Note on Pre-requisites * Privileges: You must have the 
ALTER
privilege on the resource group to add a user via a classifier. * Pipeline Engine: Resource groups require the Pipeline Engine to be enabled (it is enabled by default in v3.1.0+). References • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md References • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • sql-reference/sql-statements/account-management/ALTER_USER.md
In StarRocks, there is no single clause like 
RESOURCE GROUP = '...'
directly inside the basic 
CREATE USER
command for versions earlier than v3.3.3. However, depending on your version, you can achieve this in one or two steps. Method 1: Using User Properties (StarRocks v3.3.3 and later) From version 3.3.3 onwards, StarRocks allows you to set session variables as user properties during the 
CREATE USER
process. Since 
resource_group
is a session variable, you can assign it directly. Syntax:
Copy code
sql
CREATE USER 'jack'@'%' 
IDENTIFIED BY 'your_password'
PROPERTIES ("session.resource_group" = "your_rg_name");
Method 2: The Two-Step Approach (Recommended for All Versions) This is the standard administrative workflow. You first create the user, then associate that user with a resource group by adding a classifier. 1. Create the user:
Copy code
sql
    CREATE USER 'jack'@'%' IDENTIFIED BY 'your_password';
2. Assign to the resource group:
Copy code
sql
    ALTER RESOURCE GROUP your_rg_name ADD (user='jack');
Why Method 2 is often better: * Decoupling: Resource management is handled by the resource group, not the user object. * Granularity: Using 
ALTER RESOURCE GROUP
allows you to add more specific conditions (e.g., "only assign jack to this group when he is running 
SELECT
queries"). * Visibility: Running 
SHOW RESOURCE GROUPS ALL;
clearly shows which users are mapped to which groups via their classifiers. Summary of Differences Feature | 
CREATE USER ... PROPERTIES
 | 
ALTER RESOURCE GROUP ... ADD
 StarRocks Version | v3.3.3+ | All versions Mechanism | Session Variable | Classifier Matching Flexibility | Static (one group per user) | High (can vary by IP, query type, etc.) References • sql-reference/sql-statements/account-management/CREATE_USER.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md References • sql-reference/System_variable.md • faq/resource_isolation_faq.md • administration/management/resource_management/resource_group.md
u
@Rocky Is there any command that creating user with assigning resource group
r
Yes, you can create a user and assign a resource group in a single command, but the syntax depends on your StarRocks version. For StarRocks v3.3.3 and later You can use the 
PROPERTIES
clause in the 
CREATE USER
statement to set the 
resource_group
session variable directly for that user. Syntax:
Copy code
sql
CREATE USER 'username'@'%' 
IDENTIFIED BY 'password'
PROPERTIES ("session.resource_group" = "your_rg_name");
* How it works: This sets a user-level property. Every time this user logs in, StarRocks automatically sets their session variable 
resource_group
to the specified value. For Versions earlier than v3.3.3 There is no single command to do both. You must follow a two-step process: 1. Create the user:
Copy code
sql
    CREATE USER 'username'@'%' IDENTIFIED BY 'password';
2. Assign the user to the group via a classifier:
Copy code
sql
    ALTER RESOURCE GROUP your_rg_name ADD (user='username');
Which method should you use? * Use 
PROPERTIES
(v3.3.3+): If you want a hard-coded default group for a specific user regardless of where they connect from or what they are doing. * Use 
ALTER RESOURCE GROUP
(Classifiers): If you want more flexibility. Classifiers allow you to assign a user to different groups based on conditions like their source IP, the database they are accessing, or the type of query (e.g., 
SELECT
vs 
INSERT
). To verify the assignment:
Copy code
sql
-- To see user-level properties:
SHOW PROPERTY FOR 'username';

-- To see resource group mappings:
SHOW RESOURCE GROUPS ALL;
References • sql-reference/sql-statements/account-management/CREATE_USER.md • administration/management/resource_management/resource_group.md • sql-reference/System_variable.md References • sql-reference/sql-statements/account-management/CREATE_USER.md • sql-reference/System_variable.md • sql-reference/sql-statements/account-management/ALTER_USER.md
u
Is that possible to create resource group without classifier
@Rocky Is that possible to create resource group without classifier
r
Yes, it is possible for a resource group to exist without any classifiers, but the standard 
CREATE RESOURCE GROUP
 syntax typically requires at least one classifier to be defined during the initial creation. Here is the breakdown of how to handle this: 1. Creation Syntax Requirement According to the official StarRocks syntax, the 
TO
clause (which defines classifiers) is a standard part of the command. If you try to omit it entirely, the SQL parser may return a syntax error.
Copy code
sql
-- Standard syntax
CREATE RESOURCE GROUP <name> 
TO (user='dummy_user') -- Usually requires at least one classifier
WITH ('cpu_weight' = '10', 'mem_limit' = '20%');
2. How to "Empty" a Resource Group If you want a resource group to have no classifiers (for example, if you only plan to assign queries to it manually via session variables), you can follow these steps: 1. Create it with any classifier (e.g., a dummy user or your own account). 2. Drop all classifiers using the 
ALTER
command:
Copy code
sql
    ALTER RESOURCE GROUP <group_name> DROP ALL;
Once all classifiers are dropped, no queries will be automatically routed to this group based on user, role, or IP. 3. Using a Group Without Classifiers A resource group without classifiers is still functional. You can use it by manually assigning it at the session or user level: * Manual session assignment:
Copy code
sql
    SET resource_group = 'your_group_name';
* User-level property (v3.3.3+):
Copy code
sql
    ALTER USER 'username' SET PROPERTIES ("session.resource_group" = "your_group_name");
Summary * Is it mandatory at creation? Technically yes, the 
TO
clause is part of the 
CREATE
statement grammar. * Can a group exist without one? Yes, by using 
ALTER ... DROP ALL
. * Why do this? You might want a "quarantine" group or a special group that users must explicitly opt-into for specific heavy workloads, preventing any accidental automatic matching. References • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • sql-reference/sql-statements/cluster-management/resource_group/ALTER_RESOURCE_GROUP.md • administration/management/resource_management/resource_group.md References • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/Resource/CREATE_RESOURCE.md
u
@Rocky Is Role only used for privileges?
r
No, Roles in StarRocks are used for more than just privileges. While their primary purpose is Role-Based Access Control (RBAC), they are also a key component of Resource Management. Here are the two main ways Roles are used: 1. Privilege Management (Standard RBAC) Roles group together permissions (like 
SELECT
, 
INSERT
, or 
CREATE TABLE
) so they can be assigned to multiple users at once. This includes built-in roles like 
db_admin
and 
cluster_admin
. 2. Resource Group Assignment (Classifiers) This is the most common use of Roles outside of security. You can use a Role as a Classifier for a Resource Group. This allows you to automatically control the hardware resources (CPU, Memory, IO) for anyone holding that role. Example: If you have a role called 
data_analyst
, you can create a resource group that automatically limits or prioritizes their queries:
Copy code
sql
-- Create a resource group specifically for analysts
CREATE RESOURCE GROUP analyst_group
TO (role='data_analyst') -- Use the role as a classifier
WITH (
    "cpu_weight" = "10",
    "mem_limit" = "30%"
);
Why this is useful: * Automatic Routing: Instead of manually assigning every new analyst to a resource group, simply granting them the 
data_analyst
role will automatically subject their queries to that group's resource limits. * Dynamic Scaling: If you change a user's role, their resource priority changes immediately without needing to run 
ALTER RESOURCE GROUP
commands. Summary * Privileges: Controls what a user can do (Security). * Resource Groups: Controls how much resource a user can consume (Performance/Isolation). Roles serve as the bridge between these two systems. References • administration/management/resource_management/resource_group.md • administration/user_privs/authorization/built_in_roles.md • administration/user_privs/authorization/user_privs.md References • administration/management/resource_management/resource_group.md • administration/user_privs/authorization/built_in_roles.md • administration/user_privs/authorization/user_privs.md
u
@Rocky how can I assign role to user
r
To assign a role to a user in StarRocks, you use the 
GRANT
 command. Standard Syntax
Copy code
sql
GRANT <role_name> TO USER <user_identity>;
Example If you want to grant the role 
data_analyst
to the user 
jack
connecting from any host (
'%'
):
Copy code
sql
GRANT data_analyst TO USER 'jack'@'%';
────────── Important Considerations 1. Activating the Role By default, granting a role does not necessarily mean it is active the moment the user logs in. You have two ways to handle this: * Set as Default Role: This makes the role active automatically upon login.
Copy code
sql
    ALTER USER 'jack'@'%' DEFAULT ROLE 'data_analyst';
* Enable All Roles on Login (Recommended): You can configure StarRocks to automatically activate every role a user has been granted whenever they log in.
Copy code
sql
    SET GLOBAL activate_all_roles_on_login = TRUE;
2. Verification To check which roles have been granted to a specific user:
Copy code
sql
SHOW GRANTS FOR 'jack'@'%';
3. Required Privileges To execute these commands, you typically need to be logged in as a user with the 
user_admin
or 
root
role. References • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/GRANT.md • sql-reference/sql-statements/account-management/ALTER_USER.md References • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/GRANT.md • sql-reference/sql-statements/account-management/ALTER_USER.md • administration/user_privs/authorization/user_privs.md References • administration/user_privs/authorization/User_privilege.md • administration/user_privs/authorization/user_privs.md
u
@Rocky any user that getting "a role" use resource group that assigned to "a role"? For example if "user A" have "a role" and "b role" by grant command, then user A uses both of "a role"s resource group and "b role"s resource group?
r
No, a user cannot use two resource groups at the same time for a single query. StarRocks must pick exactly one resource group to run a query. If a user has both 
role_a
and 
role_b
active, and both roles are tied to different resource groups, StarRocks uses a "Degree of Matching" (priority system) to decide which one to use. How StarRocks Decides (The Priority Rules) When multiple classifiers match a user's session, StarRocks calculates a score for each: 1. Number of Conditions: A classifier with more specific conditions wins. _ _Example:* A classifier for 
(role='role_a', db='sales')
will beat a classifier that only says 
(role='role_a')
. 2. Tie-Breaking (Accuracy): If they have the same number of conditions, the more "accurate" or restrictive one wins (e.g., a specific IP range beats a broader one). 3. Random Selection: If both classifiers are equally specific (e.g., both just specify a single role), StarRocks will randomly select one of the two resource groups. Example Scenario * User A has both 
role_a
and 
role_b
active. * Resource Group X has a classifier: 
(role='role_a')
. * Resource Group Y has a classifier: 
(role='role_b')
. Because both classifiers have exactly one condition and the same weight (1.0), StarRocks will pick either Group X or Group Y randomly for the query. Best Practices for Multiple Roles To avoid random selection and ensure a specific role takes precedence, you can make one classifier more specific: * Option A (More conditions): Add a database or query type to the preferred role's classifier. * Option B (Manual override): The user can manually force a specific group for their current session:
Copy code
sql
    SET resource_group = 'group_x';
How to verify which group was used You can check which resource group was actually selected for a query by looking at the 
ResourceGroup
column in the FE audit log (
fe.audit.log
) or by running:
Copy code
sql
EXPLAIN VERBOSE <your_query>;
References • administration/management/resource_management/resource_group.md • faq/resource_isolation_faq.md • sql-reference/sql-statements/cluster-management/resource_group/CREATE_RESOURCE_GROUP.md References • faq/resource_isolation_faq.md • administration/management/resource_management/resource_group.md
u
@Rocky Is that possible, only grant general privileges( database usage) to roles and grant detaile privileges( select, update, delete table, database) to user. and how it works?
r
Yes, it is absolutely possible to split privileges this way. StarRocks combines Role-Based Access Control (RBAC) and Identity-Based Access Control (IBAC). How it works The total permissions of a user are the union of: 1. All privileges granted directly to the User identity. 2. All privileges granted to any active Roles assigned to that user. If a user has a role with "general" database permissions and a direct grant for "detailed" table permissions, StarRocks simply adds them together. Example Scenario You want a user named 
analyst_bob
to have general access to a database via a role, but specific write access to one table granted only to him. 1. Create a Role for general privileges:
Copy code
sql
CREATE ROLE general_access;
-- Grant basic USAGE/database-level access
GRANT USAGE ON DATABASE sales_db TO ROLE general_access;
-- Assign the role to the user
GRANT general_access TO USER 'analyst_bob'@'%';
2. Grant detailed privileges directly to the User:
Copy code
sql
-- Grant specific table-level write access directly to the user identity
GRANT SELECT, INSERT, UPDATE ON TABLE sales_db.daily_report TO USER 'analyst_bob'@'%';
Result: When 
analyst_bob
logs in: * He can see and enter the 
sales_db
database (from the Role). * He can perform 
SELECT
, 
INSERT
, and 
UPDATE
on the 
daily_report
table (from his direct User identity). * He cannot perform those actions on other tables in that database unless the role or his identity specifically allows it. Important Note on Activation For the role-based privileges to work, the role must be active. You can ensure all granted roles are active by default for all users with this global setting:
Copy code
sql
SET GLOBAL activate_all_roles_on_login = TRUE;
Why use this approach? * Scalability: Use Roles for "Standard" access levels (e.g., "Developer", "Reader") that 90% of people use. * Precision: Use direct User grants for "Exceptions" or highly sensitive tables that only one specific person should touch, without needing to create a brand new role for every single unique case. References • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/GRANT.md References • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/GRANT.md References • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/User_privilege.md
u
@Rocky In our environment, there are multi tenants in one cluster and each tenant owns databases, one resource group, users, catalogs. Also each user's privileges are different for database. What is the best practice in this situation
r
For a multi-tenant environment in StarRocks where each tenant owns specific databases, catalogs, and resource groups, the best practice is a Hybrid Access Control model. This combines Role-Based Access Control (RBAC) for standardizing tenant levels and Identity-Based Access Control (IBAC) for specific user exceptions. 1. Resource Isolation (One Group per Tenant) To ensure one tenant's heavy queries don't impact another, use Resource Groups. * Best Practice: Create one resource group per tenant and bind it to the tenant's primary role or user identity using a Classifier. * Implementation:
Copy code
sql
    CREATE RESOURCE_GROUP tenant_a_rg
    CAPACITY (cpu_core_limit = 10, mem_limit = '20%')
    INSERT CLASSIFIER (role = 'tenant_a_base_role');
_This ensures any user with the 
tenant_a_base_role
active will automatically be governed by the 
tenant_a_rg
resource limits._ 2. Privilege Hierarchy (Roles + Direct Grants) Since users within a tenant have different database privileges, use a tiered approach: * Tier 1: The Tenant Admin Role Create a "Manager" role for each tenant with 
WITH GRANT OPTION
. This allows the tenant leader to manage their own users without needing a global cluster admin.
Copy code
sql
    GRANT ALL PRIVILEGES ON DATABASE tenant_a_db TO ROLE tenant_a_admin WITH GRANT OPTION;
    GRANT USAGE ON CATALOG tenant_a_catalog TO ROLE tenant_a_admin WITH GRANT OPTION;
* Tier 2: Standard Tenant Roles Create "template" roles for common patterns (e.g., 
tenant_a_read_only
, 
tenant_a_developer
).
Copy code
sql
    GRANT SELECT ON ALL TABLES IN DATABASE tenant_a_db TO ROLE tenant_a_read_only;
* Tier 3: Individual User Exceptions (Direct Grants) For the users who need "different privileges" (e.g., one user needs access to a specific sensitive table that the standard role doesn't have), grant those directly to the User Identity.
Copy code
sql
    -- Grant general access via role
    GRANT tenant_a_read_only TO USER 'bob'@'%';
    -- Grant specific write access to one table only for Bob
    GRANT INSERT, UPDATE ON TABLE tenant_a_db.specific_table TO USER 'bob'@'%';
3. Catalog Isolation In a multi-tenant environment, metadata visibility is key. * Visibility: Users can only see catalogs and databases they have 
USAGE
or 
SELECT
permissions for. * Best Practice: Do not grant any privileges on the 
default_catalog
or other tenants' catalogs to a tenant's roles. This keeps the environment clean; when a user runs 
SHOW CATALOGS
, they only see what they own. 4. Automation & Maintenance * Default Roles: To simplify the user experience, set the tenant's base role as the default for their users:
Copy code
sql
    ALTER USER 'bob'@'%' DEFAULT ROLE 'tenant_a_read_only';
* Automatic Activation: Enable global role activation so users don't have to run 
SET ROLE
manually:
Copy code
sql
    SET GLOBAL activate_all_roles_on_login = TRUE;
Summary of the Best Practice Model 1. Resource Group: 1 per tenant (Classified by Role). 2. Database/Catalog: 1 or more per tenant. 3. Roles: Use for "Access Levels" (Admin, Dev, Read). 4. Direct Grants: Use for "Unique Exceptions" per user. 5. Delegation: Use 
WITH GRANT OPTION
to let tenants self-manage. References • administration/user_privs/authorization/User_privilege.md • administration/management/resource_management/resource_group.md • sql-reference/sql-statements/account-management/GRANT.md References • administration/user_privs/authorization/User_privilege.md
u
what is tenant base role?
@Rocky what is tenant base role?
r
A "Tenant Base Role" is not a built-in StarRocks keyword, but rather a design pattern used to manage multi-tenancy efficiently. It acts as the "anchor" for a tenant's entire environment. In a multi-tenant setup, you use this role to solve two main problems: Resource Isolation and Permission Standardisation. 1. The "Anchor" for Resource Groups In StarRocks, you can't bind a Resource Group directly to a "Tenant" (because "Tenant" isn't a native object). Instead, you bind the Resource Group to a Role. The Tenant Base Role is the specific role you use in your Resource Group classifier. By granting this role to every user in "Tenant A", you ensure that no matter what individual permissions those users have, they all share the same CPU/Memory bucket. * Example:
Copy code
sql
    -- 1. Create the 'Base Role' for the tenant
    CREATE ROLE tenant_a_base;

    -- 2. Link the Resource Group to this specific role
    CREATE RESOURCE_GROUP tenant_a_rg
    CAPACITY (cpu_core_limit = 10)
    INSERT CLASSIFIER (role = 'tenant_a_base');
2. The "Baseline" for Permissions Instead of granting every user permission to see the tenant’s database one by one, you grant it to the Base Role. This ensures that anyone added to the tenant can at least "see" the environment. * Example:
Copy code
sql
    -- Every user in Tenant A needs to see these to do anything
    GRANT USAGE ON CATALOG tenant_a_catalog TO ROLE tenant_a_base;
    GRANT USAGE ON DATABASE tenant_a_db TO ROLE tenant_a_base;
3. How it fits in a hierarchy In a mature setup, the Tenant Base Role often sits at the bottom of a hierarchy. You might have several functional roles that all "inherit" the base role. * Role Hierarchy Example: * 
tenant_a_read_only
(Inherits 
tenant_a_base
) * 
tenant_a_developer
(Inherits 
tenant_a_base
) * 
tenant_a_admin
(Inherits 
tenant_a_base
) Because all these roles inherit 
tenant_a_base
, any user assigned any of these roles will automatically trigger the 
tenant_a_rg
Resource Group because the base role is active in their session. Summary: Why use one? * Simplicity: You only need to maintain one Resource Group classifier per tenant. * Security: It creates a "walled garden." If a user doesn't have the 
tenant_a_base
role, they can't see the tenant's catalog or use their compute power. * Cleanliness: When you run 
SHOW ROLES
, it’s easy to see which roles belong to which customer (e.g., 
customer1_base
, 
customer2_base
). References • administration/user_privs/authorization/User_privilege.md • administration/management/resource_management/resource_group.md • administration/user_privs/authorization/user_privs.md References • administration/user_privs/authorization/User_privilege.md • sql-reference/sql-statements/account-management/GRANT.md
u
If I use RBAC, then why multiple user is required in one role?
@Rocky If I use RBAC, then why multiple user is required in one role?
r
In an RBAC (Role-Based Access Control) system, it is not technically required for multiple users to share one role, but it is the primary reason RBAC exists. If you were to create a unique role for every single user, you would essentially be doing "Identity-Based Access Control" but with more steps. Here is why the "Multiple Users -> One Role" model is the standard best practice: 1. Management at Scale (The "Change Once" Principle) Imagine you have 50 analysts who all need 
SELECT
access to a new table. * Without sharing roles: You would have to run 50 
GRANT
statements (one for each user). If that table is later deleted or restricted, you have to run 50 
REVOKE
statements. * With a shared role: You grant the permission to the 
analyst
role once. All 50 users immediately get access. 2. Standardizing "Job Functions" A Role represents a job function, not a person. People join the company, change teams, or leave, but the "job function" of an "Accounting Auditor" or "Data Scientist" remains the same. * When a new employee joins the "Marketing" team, you don't need to figure out which 20 tables they need. You simply give them the 
marketing_role
, and they instantly have the exact same environment as their peers. 3. StarRocks Specific: Resource Isolation In StarRocks, Resource Groups (which control CPU and Memory) are often tied to Roles via classifiers. * If you have a "Tenant A" with 10 users, you want all 10 users to share the same 20% of cluster CPU. * By putting all 10 users into a single 
tenant_a_base_role
, StarRocks can easily identify them as one group and enforce that resource limit collectively. 4. Consistency and Compliance Using shared roles prevents "permission creep." If every user has custom-granted permissions, it becomes nearly impossible for an auditor to verify that no one has accidental access to sensitive data. With roles, you only have to audit the role's permissions to know what every member can do. When should a user have a unique grant? You should use Direct User Grants (Identity-Based) only for exceptions: * A temporary project where one specific person needs access to a table for 24 hours. * A "Manager" who needs everything their team has (via the role) plus one highly sensitive HR table (via a direct grant). Summary: You put multiple users in one role so that you can manage groups of people as a single entity, ensuring they have consistent permissions and share the same resource limits. References • administration/user_privs/authorization/user_privs.md • administration/user_privs/authorization/User_privilege.md • administration/management/resource_management/resource_group.md References • administration/user_privs/authorization/User_privilege.md • administration/user_privs/authorization/user_privs.md
u
quer
2 Views
Open in Slack
PreviousNext
Powered by