Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about the principle of Nebula Graph access control in the map database. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Abstract: database rights management is familiar to everyone, but how to do a good job of database rights management? In this article, we will introduce the user management and rights management of Nebula Graph in detail.

Database rights management is already familiar to everyone. Nebula Graph itself is a high-performance mass map database, and the security of the database is the top priority of the database design. At present, Nebula Graph supports role-based access control. In this article, the user management and rights management of Nebula Graph will be described in detail.

Nebula Graph architecture

As can be seen from the figure above, the main architecture of Nebula Graph is divided into three parts: Computation Layer, Storage Layer and Meta Service. Console, API and Web Service are collectively referred to as Client API. Account data and permission data will be stored in Meta Engine, and when Query Engine is started, the initial Meta Client,Query Engine will communicate with Meta Service through Meta Client.

When a user connects to Query Engine through Client API, Query Engine will query the user data of Meta Engine through Meta Client and determine whether the connection account exists and whether the password is correct. When the authentication is passed, the connection is created successfully, and the user can perform data operations through the connection. When a user sends an operation instruction through Client API, Query Engine first parses the instruction, identifies the operation type, and judges the authority by the operation type, user role and other information. If the permission is invalid, the operation is blocked directly in Query Engine, and the error message is returned to Client API. Throughout the permission check process, Nebula Graph caches Meta data, which is described in the following sections.

Function description

Before introducing the functionality, we need to describe the logical structure of Nebula Graph: Nebula Graph is a graph database that supports multiple graph spaces (Space). Schema is managed independently in Space and Data,Space and Space are independent of each other. In addition, Nebula Graph also provides a series of advanced commands for global management of Cluster,Cluster operation commands and Space operation commands are described in detail below.

Therefore, the rights management of Nebula Graph will be based on three dimensions: Space, Role and Operation. For a detailed description, see the following sub-sections.

Role division

Nebula Graph provides five operational roles, namely GOD, ADMIN, DBA, USER and GUEST, which basically cover all data security control scenarios. A login account (Account) can have different roles in different Space, but an Account can only have one role in the same Space. Role explanation:

GOD: equivalent to the root user in the Linux operating system, with the highest administrative privileges. When Nebula Graph Cluster initializes, it creates an Account of the GOD role by default, named root.

ADMIN: a senior Space-based administrator with all administrative privileges within this Space, but no administrative privileges for the entire cluster.

DBA: database administrator who can manage Space within permissions, such as modifying and querying Schema / Data. The difference between DBA and ADMIN is that DBA cannot authorize an Account, but ADMIN can.

USER: normal database usage roles. Read and write Data, read Schema but do not have write permission.

GUEST: visitor role with read-only access to Schema and Data of Space within permissions.

The detailed permission list is shown in the following figure:

OPERATIONGODADMINDBAUSERGUESTRead SpaceYYYYYWrite SpaceY

Read SchemaYYYYYWrite SchemaYYY

Write UserY

Write RoleYY

Read DataYYYYYWrite DataYYYY

Special operationYYYYY

Note: Special Operation is a special operation, such as SHOW SPACE, which can be performed by each role, but the execution result only shows the results within the permission of Account.

Subdivision of database operation permissions

Based on the list of roles above, different roles have different operation licenses, as shown below:

OPERATIONSTATEMENTSRead Space1. USE

2. DESCRIBE SPACEWrite Space1. CREATE SPACE

2. DROP SPACE

3. CREATE SNAPSHOT

4. DROP SNAPSHOT

5. BALANCERead Schema1. DESCRIBE TAG

2. DESCRIBE EDGE

3. DESCRIBE TAG INDEX

4. DESCRIBE EDGE INDEXWrite Schema1. CREATE TAG

2. ALTER TAG

3. CREATE EDGE

4. ALTER EDGE

5. DROP TAG

6. DROP EDGE

7. CREATE TAG INDEX

8. CREATE EDGE INDEX

9. DROP TAG INDEX

10. DROP EDGE INDEXWrite User1. CREATE USER

2. DROP USER

3. ALTER USERWrite Role1. GRANT

2. REVOKE

Read Data1. GO

2. PIPE

3. LOOKUP

4. YIELD

5. ORDER BY

6. FETCH VERTEX

7. FETCH EDGE

8. FIND PATH

9. LIMIT

10. GROUP BY

11. RETURNWrite Data1. REBUILD TAG INDEX

2. REBUILD EDGE INDEX

3. INSERT VERTEX

4. UPDATE VERTEX

5. INSERT EDGE

6. UPDATE DEGE

7. DELETE VERTEX

8. DELETE EDGE

Special Operation1. SHOW,eg: SHOW SPACE 、 SHOW ROLES

2. CHANGE PASSWORD control logic

The user management and rights management of Nebula Graph are similar to those of most databases. Based on meta server, rights management is carried out at three levels: Space, Role and Operation. When Client connects to Nebula Graph Server, Nebula Graph Server will first verify the existence of login account (Account) and verify whether the password is valid.

After a successful login, Nebula Graph Server connects the initial Session ID for this and loads the Session ID, user information, permission information, and Space information into the Session structure together. Each subsequent operation will determine the permissions based on the information in the Session structure. Until the user actively exits the connection or the session timeout,Session is destroyed. In addition, Meta Client caches the permission information and synchronizes the cache according to the set time frequency, which effectively reduces the time consumption of the user connection process.

Control logic Permission Checkbool PermissionCheck::permissionCheck (session::Session * session, Sentence* sentence) {auto kind = sentence- > kind (); switch (kind) {case Sentence::Kind::kUnknown: {return false;} case Sentence::Kind::kUse: case Sentence::Kind::kDescribeSpace: {/ * Use space and Describe space are special operations. * Permission checking needs to be done in their executor. * skip the check at here. * / return true;}... Permission Check EntryStatus SequentialExecutor::prepare () {for (auto I = 0U; I

Sentences_.size (); iTunes +) {auto * sentence = sentences_- > sentences_ [I] .get (); auto executor = makeExecutor (sentence); if (FLAGS_enable_authorize) {auto * session = executor- > ectx ()-> rctx ()-> session (); / * * Skip special operations check at here. They are: * kUse, kDescribeSpace, kRevoke and kGrant. * / if (! PermissionCheck::permissionCheck (session, sentence)) {return Status::PermissionError ("Permission denied");}}.}. Sample view existing user roles (root@127.0.0.1:6999) [(none)] > SHOW USERS = | Account | = | root |-Got 1 rows (Time spent: 426.351 ms 433.756 ms) create user (root@127.0.0.1:6999) [(none)] > CREATE USER user1 WITH PASSWORD "pwd1" Execution succeeded (Time spent: 194.471 ms 201.007 ms) (root@127.0.0.1:6999) [(none)] > CREATE USER user2 WITH PASSWORD "pwd2" Execution succeeded (Time spent: 33.627max 40. 084 ms) # View existing user roles (root@127.0.0.1:6999) [(none)] > SHOW USERS = | Account | = | root |-| user1 |-| user2 |-Got 3 rows (Time spent: 24.415 ms 32.173) specify roles for different Account in Space # create graph space (root@127.0.0.1:6999) [(none)] > CREATE SPACE user_space (partition_num=1) Replica_factor=1) Execution succeeded (Time spent: 218.846 none 225.075 ms) (root@127.0.0.1:6999) [(none)] > GRANT DBA ON user_space TO user1Execution succeeded (Time spent: 203.922 Time spent 210.957 ms) (root@127.0.0.1:6999) [(none)] > GRANT ADMIN ON user_space TO user2Execution succeeded (Time spent: 36.384 Universe 49.296 ms) to view the existing roles of a specific Space (root@127.0. 0.1 Got 6999) [(none)] > SHOW ROLES IN user_space=== | Account | Role Type | = = | user1 | DBA |-- | user2 | ADMIN |-Got 2 role (Time spent: 18.637 ms 29.91 ms) cancel the role authorization for a specific Space (root@127.0.0) .1Plux 6999) [(none)] > REVOKE ROLE DBA ON user_space FROM user1Execution succeeded (Time spent: 201.924 ms 216.232) # View after cancellation User_space existing role (root@127.0.0.1:6999) [(none)] > SHOW ROLES IN user_space=== | Account | Role Type | = = | user2 | ADMIN |-Got 1 rows (Time spent: 16.645bat 32.784 ms) Delete an Account role (root@127.0.0.1:6999) [(none)] > DROP USER user2Execution succeeded (Time spent: 203) .396 user2 216.346 ms) # View the role of user2 in user_space (root@127.0.0.1:6999) [(none)] > SHOW ROLES IN user_spaceEmpty set (Time spent: 20.614 ms) # View the existing account (root@127.0.0.1:6999) [(none)] > SHOW USERS in the database = | Account | = | root |-| user1 |-Got 2 rows (Time spent: 22.692thumb 38.138 ms) the above is the principle of the Nebula Graph access control implementation of the graph database shared by the editor. If you happen to have similar doubts, please refer to the above analysis for understanding. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.