Role-Based Access Control (RBAC)

Join StarRocks Community on Slack

Connect on Slack

TABLE OF CONTENTS

See all glossary items

ACID(Atomicity, Consistency, Isolation, Durability)

MapReduce

Cardinality

Receiver Operating Characteristic (ROC) Curve

Risk Analytics

Publish date: May 22, 2024 9:19:33 PM

What Is the Role-Based Access Control?

Role-Based Access Control (RBAC) is a method used to manage user permissions within a database system. In RBAC, permissions are not assigned directly to users but to roles, which are then assigned to users. This approach simplifies permission management and enhances security by grouping related permissions together and assigning them to roles based on job functions or responsibilities.

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

StarRocks, a high-performance analytical database, implements RBAC to manage access control. Roles can be defined with specific permissions, and users can be assigned to these roles. For example:

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.

This setup allows for efficient and secure management of user permissions, ensuring that users only have the access necessary to perform their job functions.

System-Defined Roles in StarRocks

StarRocks provides several predefined roles that can be used to meet common administrative needs, such as:

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

To adhere to the principle of least privilege, roles can be assigned as default roles, which are not activated upon login unless explicitly set by the user. For example, a user with role_query and role_delete roles might have only role_query activated by default to prevent accidental data deletion. Users can manually activate other roles as needed within their session.

What Are the 4 Models of RBAC?

RBAC can be categorized into four models, each with increasing complexity and functionality:

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?

RBAC systems operate based on three primary rules:

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?

Implementing RBAC can be challenging due to several factors:

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

To build an RBAC system in StarRocks, follow these steps:

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.

StarRocks provides a comprehensive set of tools and interfaces for managing roles and permissions, making it straightforward to implement and maintain an RBAC system.

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 is not mandatory, but it is highly recommended for organizations that need to manage permissions efficiently and securely. It simplifies permission management, enhances security by enforcing the principle of least privilege, and makes it easier to comply with regulatory requirements.

In summary, RBAC is a powerful and flexible access control model that simplifies permission management in database systems like StarRocks. While it has its challenges, the benefits of improved security, simplicity, and scalability make it a preferred choice for many organizations.

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

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) is another access control model that uses attributes (such as user attributes, resource attributes, and environmental conditions) to determine access permissions. While RBAC assigns permissions based on roles, ABAC provides more granular control by considering various attributes.

In StarRocks, RBAC is typically preferred due to its simplicity and efficiency in managing permissions across a large number of users. However, for environments requiring highly granular access controls, ABAC might be more suitable. RBAC is generally easier to implement and manage, especially in systems where roles and responsibilities are well-defined.

Lightweight Directory Access Protocol (LDAP)

LDAP (Lightweight Directory Access Protocol) is a protocol used for accessing and managing directory information, such as user accounts and their attributes. RBAC, on the other hand, is a model for managing permissions. While LDAP can store user information and roles, RBAC defines how those roles are used to grant or restrict access. Essentially, LDAP can be used to implement RBAC by storing role assignments and user information, but they serve different purposes.

Identity-Based Access Control (IBAC)

Identity-Based Access Control (IBAC) assigns permissions directly to user identities. Each user is given specific permissions based on their identity rather than their role. This model is straightforward and can be suitable for smaller environments or where users have unique access requirements that do not fit well into predefined roles.

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

The choice between RBAC and IBAC depends on the specific needs and structure of the organization.

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

In practice, many database systems, including StarRocks, combine RBAC and IBAC to leverage the strengths of both models. This hybrid approach allows for the flexibility of direct permission assignments when needed, while still benefiting from the scalability and manageability of role-based permissions.

StarRocks employs a hybrid approach, combining RBAC and IBAC. The system allows for direct permission assignments to users (IBAC) while also supporting role-based permissions (RBAC). This combination provides a flexible and robust access control system that can adapt to various organizational needs.