圖數(shù)據(jù)庫Nebula Graph訪問控制實現(xiàn)原理是什么

173次閱讀

共計 5869 個字符，預(yù)計需要花費 15 分鐘才能閱讀完成。

這期內(nèi)容當中丸趣 TV 小編將會給大家?guī)碛嘘P(guān)圖數(shù)據(jù)庫 Nebula Graph 訪問控制實現(xiàn)原理是什么，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

摘要：數(shù)據(jù)庫權(quán)限管理對大家都很熟悉，然而怎么做好數(shù)據(jù)庫權(quán)限管理呢？在本文中將詳細介紹 Nebula Graph 的用戶管理和權(quán)限管理。

數(shù)據(jù)庫權(quán)限管理對大家來說都已經(jīng)很熟悉了。Nebula Graph 本身是一個高性能的海量圖數(shù)據(jù)庫，數(shù)據(jù)庫的安全問題更是數(shù)據(jù)庫設(shè)計的重中之重。目前 Nebula Graph 已支持基于角色的權(quán)限控制功能。在這篇文章中將詳細介紹 Nebula Graph 的用戶管理和權(quán)限管理。

Nebula Graph 架構(gòu)體系

由上圖可知，Nebula Graph 的主體架構(gòu)分為三部分：Computation Layer、Storage Layer 和 Meta Service。Console、API 和 Web Service 被統(tǒng)稱為 Client API。賬戶數(shù)據(jù)和權(quán)限數(shù)據(jù)將被存儲在 Meta Engine 中，當 Query Engine 啟動后，將會初始 Meta Client，Query Engine 將通過 Meta Client 與 Meta Service 進行通信。

當用戶通過 Client API 連接 Query Engine 時，Query Engine 會通過 Meta Client 查詢 Meta Engine 的用戶數(shù)據(jù)，并判斷連接賬戶是否存在，以及密碼是否正確。當驗證通過后，連接創(chuàng)建成功，用戶可以通過這個連接執(zhí)行數(shù)據(jù)操作。當用戶通過 Client API 發(fā)送操作指令后，Query Engine 首先對此指令做語法解析，識別操作類型，通過操作類型、用戶角色等信息進行權(quán)限判斷，如果權(quán)限無效，則直接在 Query Engine 阻擋操作，并返回錯誤信息至 Client API。在整個權(quán)限檢查的過程中，Nebula Graph 對 Meta data 進行了緩存，將在以下章節(jié)中介紹。

功能描述

在介紹功能之前，需要先描述一下 Nebula Graph 的邏輯結(jié)構(gòu)：Nebula Graph 是一個支持多圖空間（Space) 的圖數(shù)據(jù)庫，Space 中獨立管理 Schema 和 Data，Space 和 Space 之間相互獨立。另外，Nebula Graph 還提供了一系列高級命令用于全局管理 Cluster，Cluster 的操作命令和 Space 的操作命令將在下文中詳細描述。

因此 Nebula Graph 的權(quán)限管理將會基于圖空間（Space）、角色（Role）、操作（Operation）三個維度進行。詳細描述請看下列子章節(jié)。

角色劃分

Nebula Graph 提供了五種操作角色，分別是 GOD、ADMIN、DBA、USER、GUEST，這五種操作角色基本覆蓋了所有的數(shù)據(jù)安全控制的場景。一個登陸賬戶（Account）可以在不同的 Space 中擁有不同角色，但一個 Account 在同一個 Space 中只能擁有一種角色。角色講解：

GOD：相當于 Linux 操作系統(tǒng)中的 root 用戶，擁有最高的管理權(quán)限。Nebula Graph Cluster 在初始化時會默認創(chuàng)建一個 GOD 角色的 Account，名為 root。

ADMIN：基于 Space 的高級管理員，擁有此 Space 之內(nèi)的所有管理權(quán)限，但對整個集群則沒有管理權(quán)限。

DBA：數(shù)據(jù)庫管理員，可以對權(quán)限內(nèi)的 Space 進行管理，例如對 Schema / Data 進行修改和查詢。和 ADMIN 的區(qū)別是
DBA 不能對某個 Account 進行授權(quán)操作，但 ADMIN 可以。

USER：普通的數(shù)據(jù)庫使用角色。可讀寫 Data，可讀 Schema 但沒有寫權(quán)限。

GUEST：訪問者角色，對權(quán)限內(nèi) Space 的 Schema 和 Data 有只讀權(quán)限。

詳細權(quán)限列表如下圖所示：

OPERATIONGODADMINDBAUSERGUESTRead SpaceYYYYYWrite SpaceY

Read SchemaYYYYYWrite SchemaYYY

Write UserY

Write RoleYY

Read DataYYYYYWrite DataYYYY
Special operationYYYYY

注 : Special Operation 為特殊操作，例如 SHOW SPACE，每個角色都可以執(zhí)行，但其執(zhí)行結(jié)果只顯示 Account 權(quán)限內(nèi)的結(jié)果。

數(shù)據(jù)庫操作權(quán)限細分

基于上邊的角色列表，不同的角色擁有不同的操作許可，詳細如下：

OPERATIONSTATEMENTSRead Space1.

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.

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 控制邏輯

Nebula Graph 的用戶管理和權(quán)限管理和大多數(shù)數(shù)據(jù)庫的控制相似，基于 meta server，對圖空間（Space）、角色（Role）、操作（Operation）三個層面進行權(quán)限管理，當 Client 連接 Nebula Graph Server 的時候，Nebula Graph Server 首先會驗證登陸賬戶（Account）是否存在，并驗證密碼是否有效。

登錄成功后，Nebula Graph Server 會為此連接初始 Session ID，并將 Session ID、用戶信息、權(quán)限信息和 Space 信息一起加載到 Session 結(jié)構(gòu)中。后續(xù)的每次操作將基于 Session 結(jié)構(gòu)中的信息進行權(quán)限判斷。直到用戶主動退出連接或 session timeout，Session 銷毀。另外，Meta Client 對權(quán)限信息進行了緩存，并根據(jù)設(shè)置的時間頻率進行緩存同步，有效降低了用戶連接的過程的時間耗費。

控制邏輯代碼片段 Permission Check

bool 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 Entry

Status SequentialExecutor::prepare() { for (auto i = 0U; i   sentences_- sentences_.size(); i++) { 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 
 }
 }
 ...
}

示例查看現(xiàn)有用戶角色

(root@127.0.0.1:6999) [(none)]  SHOW USERS;
===========
| Account |
===========
| root |
-----------
Got 1 rows (Time spent: 426.351/433.756 ms)

創(chuàng)建用戶

(root@127.0.0.1:6999) [(none)]  CREATE USER user1 WITH PASSWORD  pwd1 
Execution succeeded (Time spent: 194.471/201.007 ms)
(root@127.0.0.1:6999) [(none)]  CREATE USER user2 WITH PASSWORD  pwd2 
Execution succeeded (Time spent: 33.627/40.084 ms)
#  查看現(xiàn)有用戶角色
(root@127.0.0.1:6999) [(none)]  SHOW USERS;
===========
| Account |
===========
| root |
-----------
| user1 |
-----------
| user2 |
-----------
Got 3 rows (Time spent: 24.415/32.173 ms)

為 Space 中的不同 Account 指定角色

#  創(chuàng)建圖空間
(root@127.0.0.1:6999) [(none)]  CREATE SPACE user_space(partition_num=1, replica_factor=1)
Execution succeeded (Time spent: 218.846/225.075 ms)
(root@127.0.0.1:6999) [(none)]  GRANT DBA ON user_space TO user1
Execution succeeded (Time spent: 203.922/210.957 ms)
(root@127.0.0.1:6999) [(none)]  GRANT ADMIN ON user_space TO user2
Execution succeeded (Time spent: 36.384/49.296 ms)

查看特定 Space 的已有角色

(root@127.0.0.1:6999) [(none)]  SHOW ROLES IN user_space
=======================
| Account | Role Type |
=======================
| user1 | DBA |
-----------------------
| user2 | ADMIN |
-----------------------
Got 2 rows (Time spent: 18.637/29.91 ms)

取消特定 Space 的角色授權(quán)

(root@127.0.0.1:6999) [(none)]  REVOKE ROLE DBA ON user_space FROM user1
Execution succeeded (Time spent: 201.924/216.232 ms)
#  查看取消之后，user_space  現(xiàn)有角色
(root@127.0.0.1:6999) [(none)]  SHOW ROLES IN user_space
=======================
| Account | Role Type |
=======================
| user2 | ADMIN |
-----------------------
Got 1 rows (Time spent: 16.645/32.784 ms)

刪除某個 Account 角色

(root@127.0.0.1:6999) [(none)]  DROP USER user2
Execution succeeded (Time spent: 203.396/216.346 ms)
#  查看  user2  在  user_space  的角色
(root@127.0.0.1:6999) [(none)]  SHOW ROLES IN user_space
Empty set (Time spent: 20.614/34.905 ms)
#  查看數(shù)據(jù)庫現(xiàn)有  account
(root@127.0.0.1:6999) [(none)]  SHOW USERS;
===========
| Account |
===========
| root |
-----------
| user1 |
-----------
Got 2 rows (Time spent: 22.692/38.138 ms)

上述就是丸趣 TV 小編為大家分享的圖數(shù)據(jù)庫 Nebula Graph 訪問控制實現(xiàn)原理是什么了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。

正文完