Role-Based Access Control (RBAC)

What Is the Role-Based Access Control?

What Are the Key Concepts and Features of Role-Based Access Control (RBAC)?

• Object: An entity that can be accessed, such as a catalog, database, table, or view. Access is denied unless explicitly granted.
• Action: Defines the operations that users can perform on objects, such as SELECT, DELETE, ALTER. Different types of objects support different sets of actions. For example, a VIEW object does not support DELETE, while a TABLE object does.
• Privilege: Defines what action can be performed on which object. It can be understood as a pair, such as (table1, SELECT), indicating that the user with this privilege can perform a SELECT operation on table1.
• Role: A collection of privileges and a grantable entity. Roles can be assigned to users and can also be granted to other roles to create a hierarchy. For instance, in StarRocks, you might define roles like db_admin, read_only, and data_analyst.
• User Identity: The unique identifier for a user, typically presented as username@'userhost', specifying the username and the user's login IP.

Example of RBAC in StarRocks

• db_admin: Has full permissions on all databases, including creating, modifying, and deleting tables and schemas.
• read_only: Only has permission to execute SELECT queries on the databases.
• data_analyst: Can perform SELECT queries and create temporary tables but cannot alter or delete existing data.

System-Defined Roles in StarRocks

• root: Has global permissions. The root user automatically has this role.
• cluster_admin: Manages cluster operations, including adding and removing nodes.
• db_admin: Manages databases, tables, views, materialized views, functions, resource groups, plugins, etc.
• user_admin: Manages user accounts and roles, including creating users, roles, and assigning permissions.
• public: A role that all users have by default, granting read access to information_schema.

Default Role Mechanism

What Are the 4 Models of RBAC?

• RBAC0 (Core RBAC): This is the fundamental model where roles are created and assigned permissions. Users are then assigned to these roles. This model ensures that permissions are managed through roles rather than directly to users.
• RBAC1 (Hierarchical RBAC): Extends RBAC0 by introducing role hierarchies. Roles can inherit permissions from other roles, allowing for a more organized and scalable permission structure.
• RBAC2 (Constrained RBAC): Adds constraints to RBAC0, enforcing policies such as separation of duties. This ensures that no single user can perform conflicting tasks, enhancing security.
• RBAC3 (Symmetric RBAC): Combines RBAC1 and RBAC2, providing both hierarchical roles and constraints, offering a comprehensive and flexible access control system.

What Are the Three Primary Rules for RBAC?

• Role Assignment: A subject (user) can execute a transaction only if the subject has been assigned a role.
• Role Authorization: A subject’s active role must be authorized for the subject. This ensures that users can only activate roles they are authorized to use.
• Permission Authorization: A subject can execute a transaction only if the transaction is authorized for the subject’s active role.

Why is RBAC Hard?

• Role Explosion: As the number of roles increases, managing them can become complex. Each role must be carefully defined to avoid overlaps and ensure comprehensive coverage of all required permissions.
• Role Definition: Defining roles that accurately reflect job functions and responsibilities can be difficult. This requires a deep understanding of the organization’s structure and workflows.
• Maintenance: Keeping the role and permission structure up-to-date with organizational changes requires ongoing effort. This includes adding new roles, modifying existing ones, and removing obsolete roles.
• Scalability: Ensuring that the RBAC system scales with the growth of the organization and its data can be challenging. The system must handle an increasing number of users, roles, and permissions without degrading performance.

Building an RBAC System in StarRocks

• Define Roles: Identify the different roles required in the system based on job functions. For example, roles like db_admin, read_only, and data_analyst can be defined.
• Assign Permissions to Roles: Determine the permissions each role needs and assign them accordingly. For instance, a db_admin role might have full access to all database operations, while a read_only role might only have SELECT permissions.
• Assign Users to Roles: Assign users to the appropriate roles based on their responsibilities. This can be done through the StarRocks user management interface or using SQL commands.
• Implement Role Hierarchies and Constraints: If needed, create hierarchical roles and define constraints to enforce security policies. For example, you might have a senior_db_admin role that inherits all permissions from the db_admin role and adds additional privileges.

Technical Implementation in StarRocks

• Authentication and Authorization Separation: In StarRocks, authentication and authorization are managed separately. Authentication verifies the user's identity, while authorization determines what actions the user is permitted to perform.
• AuthenticationManager: Manages user authentication using various mechanisms such as MYSQL_NATIVE_PASSWORD, LDAP, and Kerberos.
• AuthorizationManager: Manages permissions and roles, storing them in a structured and efficient manner.
• Privilege Object/Action: Represents the permissions that can be assigned to roles. For example, the SELECT action on a TABLE object.
• Privilege Entry/Collection: Stores the permissions assigned to users and roles. A collection of privilege entries allows for efficient permission checking and management.
• Grant/Revoke Mechanisms: Allows administrators to grant or revoke permissions from users or roles using SQL commands.

Is RBAC Mandatory?

RBAC vs. ABAC, LDAP, and IBAC: Which Is Better?

Attribute-Based Access Control (ABAC)

Lightweight Directory Access Protocol (LDAP)

Identity-Based Access Control (IBAC)

Key Features of IBAC

• Direct Permission Assignment: Permissions are assigned directly to user identities.
• Simplicity: IBAC is easy to implement and manage in smaller environments where the number of users and permissions is limited.
• Fine-Grained Control: Each user can have a unique set of permissions tailored to their specific needs.

Challenges with IBAC

• Scalability: As the number of users increases, managing individual permissions becomes complex and error-prone.
• Maintenance: Keeping track of individual permissions for each user can be challenging, especially in dynamic environments where user roles and responsibilities change frequently.
• Lack of Role Hierarchies: IBAC does not support role hierarchies, making it difficult to implement organized and scalable permission structures.

RBAC vs. IBAC

• RBAC is generally preferred for larger organizations with well-defined roles and responsibilities. It simplifies permission management, enhances security, and scales well as the organization grows.
• IBAC may be more suitable for smaller organizations or environments where users have unique access requirements that do not fit into predefined roles. It provides fine-grained control over permissions but can become challenging to manage as the organization grows.

Combining RBAC and IBAC