Role-Based Access Control (RBAC) for SingleStore Helios

Benefits of RBAC

• Increased security: With RBAC, access to SingleStore Helios is strictly limited to those who need it. This greatly reduces the risk of unauthorized access or changes to the network.

• Least privilege principle: RBAC aligns with the principle of least privilege, which means that users only have the rights they need to perform their job functions and nothing more. This prevents excessive permissions that could lead to security risks.

• Efficient access management: RBAC allows you to manage users' access rights efficiently. Instead of manually assigning or changing rights for every individual user, you can assign or revoke roles with predefined permissions.

• Scalability: RBAC scales well as your organization grows. As you add more users, it becomes more beneficial to manage access rights through roles rather than on an individual basis.

• Regulatory compliance: Many regulatory standards require strict control over who has access to critical data and systems. RBAC helps meet such requirements.

• Reduced chance of human error: By limiting who can make changes to access via the SingleStore Helios portal, you reduce the chance of human error leading to network issues.

RBAC Framework Implementation

SingleStore Helios RBAC restricts individual database users' access to resources by setting up a role-based environment. Each user is assigned one or more roles based on their functionality. User permissions in a cloud deployment are tied to the hierarchy of the objects associated with the organization.

Objects Associated with Users and Roles in the Cloud RBAC Framework

• Organization: This is the highest level resource that is tied to a customer. Organizations have a 1:1 mapping to customers.

  • At this level, you can view all the workspaces, workspace groups, databases, etc.

  • Billing is done at the organization level but visibility is available at the workspace group level.

  • Members can be added and removed from the organization at this level.

• Team: This is a group of users. A predefined set of teams corresponding to the organization level roles are created when RBAC is enabled. Additional teams may be created to identify groups of users with specific access roles. Users can be added or removed from the team(s).

• Workspace group: This is a set of workspaces grouped together.

• Workspace: This is an independent deployment of compute resources that can be used to run a workload. Workspaces are isolated instances and can read multiple databases. They are useful in maintaining separate environments for example for production and development.

• Database: A database contains objects such as tables, views, stored procedures, pipelines etc. The RBAC framework for organization users in the SingleStore Helios portal does not enforce any access control on databases. All data access is controlled by the RBAC framework for database users in the database engine,

Difference Between Teams and Roles

Teams simplify granting access to users with similar functions. Users can be added to any of the default teams or any custom team when they are invited into an organization or later. This allows a user to be added to the organization for a specific function (for example, an Operator or an Observer) as part of the invitation process. You do not have to explicitly grant or revoke roles to each user at the organization level.

If you want to control access at a lower level, i.e., at the individual workspace group level, then you will need to grant roles. You can grant roles directly to users or you can create teams that are granted roles and then just manage membership in these team(s).

Cloud User and Role Synchronization with the Database Engine

SingleStore Helios RBAC does not directly provide any access control to actions performed in the SingleStore database engine. In the engine, access is controlled by the database RBAC features. Cloud user and role synchronization provides a unified user experience for basic security patterns. More complex patterns, such as limited access to specific databases or defining custom database roles, are performed with SQL security management commands in the engine.

When a user is granted any role in a workspace group, synchronization automatically takes place with a corresponding user group existing in the engine. In the backend, engine user groups are granted roles with permissions appropriate for the Cloud RBAC role.

Refer here for the pre-defined mapping between Cloud RBAC roles and the engine user groups and roles.

Rules for the RBAC Framework

• Ownership of objects: Owners of a parent object are the only users allowed to create child objects. For example, only organization owners can create a workspace group. Object owners inherit the owner role on all child objects. Organization owners are owners of all objects in the organization.

• Inheritance of roles in object hierarchy: There is an inheritance of ownership of objects. For example, owners of workspace groups are also owners of all workspaces in the group.

• Granting of privileges and roles: This is not limited to users but can also be given to a group which is a collection of users.