From eb32ee2fa94536e41a25e252742188f73591bbe4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E6=9C=B1=E6=99=93=E9=9D=92?= <86282370+izhuxiaoqing@users.noreply.github.com> Date: Wed, 8 Sep 2021 11:35:35 +0800 Subject: [PATCH 1/2] authentication --- .../10.tag-statements/2.drop-tag.md | 4 +- .../1.authentication/1.authentication.md | 24 +-- .../1.authentication/2.management-user.md | 152 +++++++++--------- .../1.authentication/3.role-list.md | 62 ++++--- 4 files changed, 127 insertions(+), 115 deletions(-) diff --git a/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md b/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md index fe533f52c0f..7eed3de446a 100644 --- a/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md +++ b/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md @@ -4,9 +4,9 @@ A vertex can have one or more tags. -- If a vertex has only one tag, the vertex **CANNOT** be accessed after you drop it. But its edges are available. The vertex will be deleted in the next compaction. +- If a vertex has only one tag, the vertex **CANNOT** be accessed after you delete it. But its edges are available. The vertex will be deleted in the next compaction. -- If a vertex has multiple tags, the vertex is still accessible after you drop one of them. But all the properties defined by this dropped tag **CANNOT** be accessed. +- If a vertex has multiple tags, the vertex is still accessible after you delete one of them. But all the properties defined by this deleted tag **CANNOT** be accessed. This operation only deletes the Schema data. All the files or directories in the disk will not be deleted directly until the next compaction. diff --git a/docs-2.0/7.data-security/1.authentication/1.authentication.md b/docs-2.0/7.data-security/1.authentication/1.authentication.md index f213ae2f4bd..17d1986de52 100644 --- a/docs-2.0/7.data-security/1.authentication/1.authentication.md +++ b/docs-2.0/7.data-security/1.authentication/1.authentication.md @@ -2,21 +2,21 @@ Nebula Graph replies on local authentication or LDAP authentication to implement access control. -Nebula Graph creates a session when a client connects to it. The session stores information about the connection, including the user information. +Nebula Graph creates a session when a client connects to it. The session stores information about the connection, including the user information. If the authentication system is enabled, the session will be mapped to corresponding users. -By default, authentication is disabled and Nebula Graph allows connections with the username `root` and any password. If the authentication system is enabled, Nebula Graph checks a session according to the authentication configuration, and decides whether the session should be allowed or denied. +!!! Note -## Local authentication + By default, the authentication is disabled and Nebula Graph allows connections with the username `root` and any password. -Local authentication indicates that usernames and passwords are stored locally on the server, with the passwords encrypted. +Nebula Graph supports local authentication and LDAP authentication. -### Enable local authentication +## Local authentication -1. In the `/usr/local/nebula/etc/nebula-graphd.conf` file, set `--enable_authorize=true` and save the modification. +Local authentication indicates that usernames and passwords are stored locally on the server, with the passwords encrypted. Users will be authenticated when trying to visit Nebula Graph. - !!! note +### Enable local authentication - `/usr/local/nebula/` is the default installation path for Nebula Graph. If you have changed it, use the actual path. +1. Modify the `nebula-graphd.conf` file (`/usr/local/nebula/etc/` is the default path), set `--enable_authorize=true` and save the modification. 2. Restart the Nebula Graph services. For how to restart, see [Manage Nebula Graph services](../../2.quick-start/5.start-stop-service.md). @@ -26,10 +26,10 @@ Local authentication indicates that usernames and passwords are stored locally o ## LDAP authentication -!!! Enterpriseonly +Lightweight Directory Access Protocol (LDAP) is a lightweight client-server protocol for accessing directories and building a centralized account management system. LDAP authentication and local authentication can be enabled at the same time, but LDAP authentication has a higher priority. If the local authentication server and the LDAP server both have the information of user `Amber`, Nebula Graph reads from the LDAP server first. - LDAP authentication is an Enterprise-only feature. For how to enable LDAP, see Authenticate with an LDAP server (TODO: doc). +### Enable LDAP authentication -Lightweight Directory Access Protocol (LDAP), is a lightweight client-server protocol for accessing directories and building a centralized account management system. +!!! Enterpriseonly -LDAP authentication and local authentication can be enabled at the same time, but LDAP authentication has a higher priority. If the local authentication server and the LDAP server both have the information of user `Amber`, Nebula Graph reads from the LDAP server first. + LDAP authentication is an Enterprise-only feature. For how to enable LDAP, see Authenticate with an LDAP server (TODO: doc). diff --git a/docs-2.0/7.data-security/1.authentication/2.management-user.md b/docs-2.0/7.data-security/1.authentication/2.management-user.md index 51840062856..c5abeb24a0d 100644 --- a/docs-2.0/7.data-security/1.authentication/2.management-user.md +++ b/docs-2.0/7.data-security/1.authentication/2.management-user.md @@ -1,50 +1,66 @@ # User management -This topic describes how to manage users and roles. +User management is an indispensable part of Nebula Graph access control. This topic describes how to manage users and roles. -By default, Nebula Graph allows connections with the username `root` and any password. After [enabling authentication](1.authentication.md), only valid users can connect to Nebula Graph and access the resources according to the [user roles](3.role-list.md). +After [enabling authentication](1.authentication.md), only valid users can connect to Nebula Graph and access the resources according to the [user roles](3.role-list.md). + +!!! Note + + * By default, the authentication is disabled. Nebula Graph allows connections with the username `root` and any password. + * Once the role of a user is modified, the user has to re-login to make the new role takes effect. -Once the role of a user is modified, the user has to re-login to make the new role takes effect. ## CREATE USER -The `root` user with the GOD role can run `CREATE USER` to create a new user. +The `root` user with the **GOD** role can run `CREATE USER` to create a new user. * Syntax - ```ngql - CREATE USER [IF NOT EXISTS] [WITH PASSWORD '']; - ``` + ```ngql + CREATE USER [IF NOT EXISTS] [WITH PASSWORD '']; + ``` * Example - ```ngql - nebula> CREATE USER user1 WITH PASSWORD 'nebula'; - ``` + ```ngql + nebula> CREATE USER user1 WITH PASSWORD 'nebula'; + ``` ## GRANT ROLE -Users with the GOD role or the ADMIN role can run `GRANT ROLE` to assign a built-in role in a graph space to a user. For more information about Nebula Graph built-in roles, see [Roles and privileges](3.role-list.md) +Users with the **GOD** role or the **ADMIN** role can run `GRANT ROLE` to assign a built-in role in a graph space to a user. For more information about Nebula Graph built-in roles, see [Roles and privileges](3.role-list.md). -!!! note +* Syntax + + ```ngql + GRANT ROLE ON TO ; + ``` - If the target user is connected to Nebula Graph when running `GRANT ROLE`, the new role takes effect when the user logs out and logs in again. +* Example + + ```ngql + nebula> GRANT ROLE USER ON basketballplayer TO user1; + ``` + +## REVOKE ROLE + +Users with the **GOD** role or the **ADMIN** role can run `REVOKE ROLE` to revoke the built-in role of a user in a graph space. For more information about Nebula Graph built-in roles, see [Roles and privileges](3.role-list.md). * Syntax - ```ngql - GRANT ROLE ON TO ; - ``` + ```ngql + REVOKE ROLE ON FROM ; + ``` * Example - ```ngql - nebula> GRANT ROLE USER ON basketballplayer TO user1; - ``` + ```ngql + nebula> REVOKE ROLE USER ON basketballplayer FROM user1; + ``` ## SHOW ROLES -Run `SHOW ROLES` to list the roles in a graph space. +Users can run `SHOW ROLES` to list the roles in a graph space. * Syntax @@ -63,99 +79,79 @@ Run `SHOW ROLES` to list the roles in a graph space. +---------+-----------+ ``` -## REVOKE ROLE - -Users with the GOD role or the ADMIN role can run `REVOKE ROLE` to revoke a user's role in a graph space. - -!!! note - - If the target user is connected to Nebula Graph when running `REVOKE ROLE`, the old role still takes effect until the user logs out. - -* Syntax - - ```ngql - REVOKE ROLE ON FROM ; - ``` - -* Example - - ```ngql - nebula> REVOKE ROLE USER ON basketballplayer FROM user1; - ``` - ## CHANGE PASSWORD -With the correct username and password, users can run `CHANGE PASSWORD` to set a new password for a user. +Users can run `CHANGE PASSWORD` to set a new password for a user. The old password is needed when setting a new one. * Syntax - ```ngql - CHANGE PASSWORD FROM '' TO ''; - ``` + ```ngql + CHANGE PASSWORD FROM '' TO ''; + ``` * Example - ```ngql - nebula> CHANGE PASSWORD user1 FROM 'nebula' TO 'nebula123'; - ``` + ```ngql + nebula> CHANGE PASSWORD user1 FROM 'nebula' TO 'nebula123'; + ``` ## ALTER USER -The `root` user with the GOD role can run `ALTER USER` to set a new password for a user. +The `root` user with the **GOD** role can run `ALTER USER` to set a new password for a user. The old password is not needed when setting a new one. * Syntax - ```ngql - ALTER USER WITH PASSWORD ''; - ``` + ```ngql + ALTER USER WITH PASSWORD ''; + ``` * Example - ```ngql - nebula> ALTER USER user1 WITH PASSWORD 'nebula'; - ``` + ```ngql + nebula> ALTER USER user1 WITH PASSWORD 'nebula'; + ``` ## DROP USER -The `root` user with the GOD role can run `DROP USER` to remove a user. +The `root` user with the **GOD** role can run `DROP USER` to remove a user. !!! note - Removing a user does not close the user's current session, and the user role still takes effect in the session until the session is closed. + Removing a user does not close the current session of the user, and the user role still takes effect in the session until the session is closed. * Syntax - ```ngql - DROP USER [IF EXISTS] ; - ``` + ```ngql + DROP USER [IF EXISTS] ; + ``` * Example - ```ngql - nebula> DROP USER user1; - ``` + ```ngql + nebula> DROP USER user1; + ``` ## SHOW USERS -The `root` user with the GOD role can run `SHOW USERS` to list all the users. +The `root` user with the **GOD** role can run `SHOW USERS` to list all the users. * Syntax - ```ngql - SHOW USERS; - ``` + ```ngql + SHOW USERS; + ``` * Example - ```ngql - nebula> SHOW USERS; - +-----------+ - | Account | - +-----------+ - | "test1" | - +-----------+ - | "test2" | - +-----------+ - | "test3" | - +-----------+ - ``` + ```ngql + nebula> SHOW USERS; + +-----------+ + | Account | + +-----------+ + | "test1" | + +-----------+ + | "test2" | + +-----------+ + | "test3" | + +-----------+ + ``` diff --git a/docs-2.0/7.data-security/1.authentication/3.role-list.md b/docs-2.0/7.data-security/1.authentication/3.role-list.md index d4456f3c345..e32932ae25f 100644 --- a/docs-2.0/7.data-security/1.authentication/3.role-list.md +++ b/docs-2.0/7.data-security/1.authentication/3.role-list.md @@ -1,54 +1,70 @@ # Roles and privileges -A role is a collection of privileges. You can assign a role to a user for access control. +A role is a collection of privileges. You can assign a role to a [user](2.management-user.md) for access control. ## Built-in roles Nebula Graph does not support custom roles, but it has multiple built-in roles: * GOD - * GOD is the original role with all privileges not limited to graph spaces. It is similar to `root` in Linux and `administrator` in Windows. + + * GOD is the original role with **all privileges** not limited to graph spaces. It is similar to `root` in Linux and `administrator` in Windows. + * When the Meta Service is initialized, the one and only GOD role user `root` is automatically created with the password `nebula`. - !!! note - Modify the password for `root` as soon as possible for security. - * The default username `root` is immutable. - * If [authentication](1.authentication.md) is disabled, you can use any username and password to connect to Nebula Graph. This user is regarded as the GOD role. + !!! caution + + Modify the password for `root` timely for security. + + * One cluster can only have one user with the GOD role. This user can manage all graph spaces in a cluster. + + * Manual authorization of the God role is not supported. Only the `root` user with the default God role can be used. * ADMIN - * An ADMIN role can read and write both the Schema and the data in a specific graph space. + + * An ADMIN role can **read and write** both the Schema and the data in a specific graph space. + * An ADMIN role of a graph space can grant DBA, USER, and GUEST roles in the graph space to other users. + !!! note + + Only roles lower than ADMIN can be authorized to other users. + * DBA - * A DBA role can read and write both the Schema and the data in a specific graph space. + + * A DBA role can **read and write** both the Schema and the data in a specific graph space. + * A DBA role of a graph space CANNOT grant roles to other users. * USER - * A USER role can read and write data in a specific graph space. - * The Schema information is read-only to the USER roles in a graph space. + + * A USER role can **read and write** data in a specific graph space. + + * The Schema information is **read-only** to the USER roles in a graph space. * GUEST - * A GUEST role can only read the Schema and the data in a specific graph space. + * A GUEST role can **only read** the Schema and the data in a specific graph space. !!! note - A user can have only one role in a graph space. + * Nebula Graph does not support custom roles. Users can only use the default built-in roles. + * A user can have only one role in a graph space. For authenticated users, see [User management](2.management-user.md). ## Role privileges and allowed nGQL The privileges of roles and the nGQL statements that each role can use are listed as follows. -Privilege|God|Admin|DBA|User|Guest|Allowed nGQL| -|-|-|-|-|-|-|-| -|Read space|Y|Y|Y|Y|Y|`USE`, `DESCRIBE SPACE`| -|Write space|Y|||||`CREATE SPACE`, `DROP SPACE`, `CREATE SNAPSHOT`, `DROP SNAPSHOT`, `BALANCE DATA`, `BALANCE DATA STOP`, `BALANCE DATA REMOVE`, `BALANCE LEADER`, `ADMIN`, `CONFIG`, `INGEST`, `DOWNLOAD`, `SUBMIT JOB COMPACT`, `SUBMIT JOB FLUSH`, `SUBMIT JOB STATS`, `STOP JOB`, `RECOVER JOB`, `BUILD TAG INDEX`, `BUILD EDGE INDEX`| -|Read schema|Y|Y|Y|Y|Y|`DESCRIBE TAG`, `DESCRIBE EDGE`, `DESCRIBE TAG INDEX`, `DESCRIBE EDGE INDEX`| -|Write schema|Y|Y|Y|||`CREATE TAG`, `ALTER TAG`, `CREATE EDGE`, `ALTER EDGE`, `DROP TAG`, `DROP EDGE`, `CREATE TAG INDEX`, `CREATE EDGE INDEX`, `DROP TAG INDEX`, `DROP EDGE INDEX`| -|Write user|Y|||||`CREATE USER`, `DROP USER`, `ALTER USER`| -|Write role|Y|Y||||`GRANT`, `REVOKE`| -|Read data|Y|Y|Y|Y|Y|`GO`, `SET`, `PIPE`, `MATCH`, `ASSIGNMENT`, `LOOKUP`, `YIELD`, `ORDER BY`, `FETCH VERTICES`, `Find`, `FETCH EDGES`, `FIND PATH`, `LIMIT`, `GROUP BY`, `RETURN`| -|Write data|Y|Y|Y|Y||`INSERT VERTEX`, `UPDATE VERTEX`, `INSERT EDGE`, `UPDATE EDGE`, `DELETE VERTEX`, `DELETE EDGES`, `DELETE TAG`| -|Show operations|Y|Y|Y|Y|Y|`SHOW`, `CHANGE PASSWORD`| + |Privilege|God |Admin|DBA|User|Guest|Allowed nGQL| + |:---|:---|:---|:---|:---|:---|:---| + |Read space|Y|Y|Y|Y|Y|`USE`, `DESCRIBE SPACE`| + |Write space|Y|||||`CREATE SPACE`, `DROP SPACE`, `CREATE SNAPSHOT`, `DROP SNAPSHOT`, `BALANCE DATA`, `BALANCE DATA STOP`, `BALANCE DATA REMOVE`, `BALANCE LEADER`, `ADMIN`, `CONFIG`, `INGEST`, `DOWNLOAD`, `SUBMIT JOB COMPACT`, `SUBMIT JOB FLUSH`, `SUBMIT JOB STATS`, `STOP JOB`, `RECOVER JOB`, `BUILD TAG INDEX`, `BUILD EDGE INDEX`| + |Read schema|Y|Y|Y|Y|Y|`DESCRIBE TAG`, `DESCRIBE EDGE`, `DESCRIBE TAG INDEX`, `DESCRIBE EDGE INDEX`| + |Write schema|Y|Y|Y|||`CREATE TAG`, `ALTER TAG`, `CREATE EDGE`, `ALTER EDGE`, `DROP TAG`, `DROP EDGE`, `CREATE TAG INDEX`, `CREATE EDGE INDEX`, `DROP TAG INDEX`, `DROP EDGE INDEX`| + |Write user|Y|||||`CREATE USER`, `DROP USER`, `ALTER USER`| + |Write role|Y|Y||||`GRANT`, `REVOKE`| + |Read data|Y|Y|Y|Y|Y|`GO`, `SET`, `PIPE`, `MATCH`, `ASSIGNMENT`, `LOOKUP`, `YIELD`, `ORDER BY`, `FETCH VERTICES`, `Find`, `FETCH EDGES`, `FIND PATH`, `LIMIT`, `GROUP BY`, `RETURN`| + |Write data|Y|Y|Y|Y||`INSERT VERTEX`, `UPDATE VERTEX`, `INSERT EDGE`, `UPDATE EDGE`, `DELETE VERTEX`, `DELETE EDGES`, `DELETE TAG`| + |Show operations|Y|Y|Y|Y|Y|`SHOW`, `CHANGE PASSWORD`| !!! note From 6e5fc3945380c88e1ded6dbcebaf873a7a1d33e6 Mon Sep 17 00:00:00 2001 From: "max.zhu@vesoft.com" <86282370+izhuxiaoqing@users.noreply.github.com> Date: Fri, 10 Sep 2021 15:25:22 +0800 Subject: [PATCH 2/2] Update 2.drop-tag.md --- docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md b/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md index 7eed3de446a..67ebf46c8dd 100644 --- a/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md +++ b/docs-2.0/3.ngql-guide/10.tag-statements/2.drop-tag.md @@ -4,9 +4,9 @@ A vertex can have one or more tags. -- If a vertex has only one tag, the vertex **CANNOT** be accessed after you delete it. But its edges are available. The vertex will be deleted in the next compaction. +- If a vertex has only one tag, the vertex **CANNOT** be accessed after you drop it. But its edges are available. The vertex will be dropped in the next compaction. -- If a vertex has multiple tags, the vertex is still accessible after you delete one of them. But all the properties defined by this deleted tag **CANNOT** be accessed. +- If a vertex has multiple tags, the vertex is still accessible after you drop one of them. But all the properties defined by this dropped tag **CANNOT** be accessed. This operation only deletes the Schema data. All the files or directories in the disk will not be deleted directly until the next compaction.