Skip to content

Role-Based Access Control (RBAC)

Overview

MatrixOne Intelligence's permission management helps you manage the lifecycle oftenants anduser accounts, assign appropriateroles to users, and control access to resources within MatrixOne Intelligence. When a database has multiple users, permission management ensures they only access authorized resources, and applying theprinciple of least privilege helps reduce enterprise information security risks. In MatrixOne Intelligence, data and resources owned by each tenant within their respective instances are securely isolated, meaning users across instances can't access resources belonging to other instances.

MatrixOne Intelligence Permission Management Features

MatrixOne Intelligence's permission management is designed and implemented by combining two security models:Role-Based Access Control (RBAC) andDiscretionary Access Control (DAC). These are neutral access control mechanisms primarily focused on roles and permission authorization strategies. This design ensures secure data access while offering flexible and convenient management for database administrators.

*Role-Based Access Control (RBAC): Permissions are assigned to roles, and then roles are assigned to users.

*Discretionary Access Control (DAC): Each object has an owner, and that owner can set and grant access permissions to their object.

Key Concepts

Object

In MatrixOne Intelligence, to streamline the management of various operational permissions, permissions are encapsulated within an entity called anobject.

Relationships Between Objects

A MatrixOne Intelligence account can create multipleinstances, and each instance functions as atenant (Account). Within a tenant, you can create multipleusers androles, and within a database, you can create multipletables andviews.

While the operational permissions within each object in MatrixOne Intelligence are independent (e.g., the SHOW TABLES permission for a Database object has no direct relation to the SELECT permission for a Table object), there's a creation-based association between objects. For instance, the CREATE TABLE permission within a Database object allows the creation of Table objects, forming ahierarchical relationship between them.

Because higher-level objects can create lower-level ones, the higher-level object is considered theobject's creator (Owner).

Object Owner

When an object is created, the creator becomes itsOwner. The Owner possesses the highest management privileges for that object, known asOwnership permission, which encapsulates all permissions for that object. Therefore, the Owner's operational permissions include all possible operations for that object.

For example, a Table object has Select, Insert, Update, Delete, Truncate, and Ownership permissions. If a role possesses the Ownership permission for a specific Table, that role is equivalent to having Select, Insert, Update, Delete, and Truncate permissions.

Due to the transitive nature of permissions, roles, and users, you can think of the object's creator (referred to as the objectOwner below) as a role.

How is the object's creator a role?

A user can hold multiple roles simultaneously. For example, User A might have Role 1, Role 2, and Role 3, with each role having different permissions. The diagram below illustrates this behavior:

Suppose User A is currently using Role 1. User A needs to create a new user, New User B. However, Role 1 doesn't have permission to create new users, but Role 2 does. In this case, User A needs to switch to Role 2 to create the new user. Consequently, New User B's Owner will be Role 2; Role 1 and Role 3 will not have ownership of New User B.

Key points about Object Owners:

  • The object'sOwner is a role, and the object's initial Owner is the role that created it.
  • An object hasonly one Owner at any given time.
  • A role can create multiple objects, so a role can be the Owner of multiple objects.
  • Arole itself is also an object, and therefore, a role also has an Owner.
  • When an object's Owner is deleted, the object's Owner automatically changes to the deleted role's Owner.
  • Ownership can betransferred to another role.

Note: While ACCOUNTADMIN (the tenant administrator role, automatically generated when a tenant is created) is not the Owner of all objects within the tenant, it possesses theOwnership permission for all objects.

Tenant

MatrixOne Intelligence can create and manage multiple tenants with completely isolated data and user permission systems. Managing these isolated tenants saves costs associated with deploying and maintaining multiple data business systems and maximizes machine cost savings by sharing hardware resources among tenants.

In MatrixOne Intelligence, a tenant is referred to as anAccount, and one instance corresponds to one tenant.

Role

Arole is also an object in MatrixOne Intelligence, used for managing and assigning permissions.

Within a tenant, if a user isn't assigned a role, they can't perform any operations. First, a high-privilege account needs to perform initial resource allocation. For example, thetenant creates roles and users, grants object permissions to roles, and then assigns those roles to users. At this point, users can operate on the objects.

The purpose of establishingroles is to reduce the operational cost of granting the same permissions repeatedly. If permissions p1, p2, and p3 need to be granted to users u1, u2, and u3, you can simply grant p1, p2, and p3 to role r1 first, and then grant role r1 to users u1, u2, and u3 all at once. This is much simpler than granting each permission to each user individually, and this advantage becomes even more significant as the number of users and permissions grows. Additionally, roles further abstract permission sets and their relationships, which is very convenient for future permission maintenance.

After a MatrixOne Intelligence cluster and tenant (Account) are created, somedefault roles and users are automatically generated (see the "Initialize Access" section below). These roles have the highest management privileges and are used for initial cluster and tenant (Account) management. We don't recommend granting these roles to users who perform daily SQL operations, as excessive permissions can introduce more security issues. Therefore, MatrixOne Intelligence supports creatingcustom roles, allowing you to define roles based on users' business needs and then assign appropriate permissions to these roles.

Key points about Roles:

In MatrixOne Intelligence, the detailed behavior of roles is as follows:

  • A role can be grantedmultiple permissions.
  • A role can be granted tomultiple users.
  • A role cantransfer its permissions to another role.
    • This means giving all permissions of one role to another role. For example, if role1's permissions are transferred to role2, then role2 inherits role1's permissions.
  • Roles and users are effective only within their respectivetenants (Accounts), including the system tenant (Sys Account).

!!! note 1. Role permission inheritance isdynamic. If the inherited role's permissions change, the inheriting role's inherited permission scope will also change dynamically. 2. Role inheritance relationshipscannot form a cycle. For example, role1 inheriting role2, role2 inheriting role3, and role3 inheriting role1 is not allowed. 3. While permission transfer between roles makes permission management more convenient, it also carries risks. For this reason, MatrixOne Intelligence only allows roles with the Manage Grants permission to perform such operations. This permission isdefaulted to the system default roles MOADMIN or ACCOUNTADMIN, and it'snot recommended to grant this permission to custom roles when creating them.

Role Switching

A user can be granted multiple roles to perform different types of data operations.

Primary Role: A user can only use one role at a time; this currently used role is called theprimary role. Secondary Roles: All other roles owned by the user, apart from the primary role, are calledsecondary roles.

By default, if a user wants to execute SQL with permissions from another role, they need to firstswitch roles (i.e., set role <role>). Additionally, to maintain compatibility with classic database permission behavior, MatrixOne Intelligence also supports enabling the "use secondary roles" feature: by executing set secondary role all, the user will then possess the permissions of all their roles simultaneously. Executing set secondary role none disables this feature.

Application Scenarios

Resource Isolation Scenario

Company A has purchased and deployed MatrixOne Intelligence. Given Company A's large size, numerous and complex business lines, and vast data volume, they want to develop an application for a specific business line, let's call it BusinessApp, but need to isolate its data from other business lines. How can MatrixOne isolate these data and permission resources?

After deploying MatrixOne Intelligence, Tom from the R\&D department obtains the tenant administrator account, and the company assigns him the task of resource isolation. Tom needs to do the following:

  1. Tom logs into MatrixOne Intelligence using the tenant administrator account.
  2. Tom needs to first create two tenants: one account named BusinessAccount and another named ElseAccount.
    • The data resources within BusinessAccount will primarily be used for developing the BusinessApp application.
    • The data resources within ElseAccount can be used for other business purposes.

User Creation and Authorization Scenario

Continuing with the previous scenario, Tom gives the BusinessAccount tenant account to the company's data administrator, Robert, so Robert can assign new user accounts and permissions to other R\&D colleagues.

R\&D colleague Joe is an application developer for Company A's BusinessApp project. Joe has a development task that requires full access to all data within the database. So, Robert needs to set up an account for Joe and grant him permissions:

  1. Robert first creates a user account for Joe, named Joe_G. Joe then uses Joe_G to log into MatrixOne.
  2. Robert then creates a role for Joe, named Appdeveloper, and assigns the Appdeveloper role to Joe's user account, Joe_G.
  3. Robert then grants the Appdeveloper role the ALL ON DATABASE permission.
  4. Joe can now use the Joe_G account to log into MatrixOne and have full permission to operate the database for development.

Initialize Access

After initializing the account, the system automatically generates some default users and default roles:

Username Explanation Roles Owned Permissions Owned Description
<Custom> Tenant Admin ACCOUNTADMIN Manages all resources under normal tenants, including users, roles, databases/tables/views, and authorization management. Automatically generated and granted when the tenant is created.
All users Normal users PUBLIC Connects to MatrixOne Intelligence. All users are automatically granted the PUBLIC role upon creation.