From b97ae9030bd6126a58f99d568a143f602147ee26 Mon Sep 17 00:00:00 2001 From: matea16 Date: Thu, 28 Aug 2025 13:24:12 +0200 Subject: [PATCH] fixes in rbac --- .../role-based-access-control.mdx | 217 +++++++++++------- 1 file changed, 136 insertions(+), 81 deletions(-) diff --git a/pages/database-management/authentication-and-authorization/role-based-access-control.mdx b/pages/database-management/authentication-and-authorization/role-based-access-control.mdx index 7ae979e56..130fa1f07 100644 --- a/pages/database-management/authentication-and-authorization/role-based-access-control.mdx +++ b/pages/database-management/authentication-and-authorization/role-based-access-control.mdx @@ -5,46 +5,53 @@ description: Learn how to set up role-based access control. import { Callout } from 'nextra/components' -# Role-based access control (Enterprise) +# Role-based access control Enterprise -Role-Based access control (RBAC) simplifies data security by grouping users into -roles based on their tasks. Instead of assigning permissions to each user, RBAC -assigns privileges to roles. Users, when linked to roles, gain the necessary -access for their responsibilities. For example, in a company, a manager's role -might have different access levels than an employee's role. Through RBAC, -organizations efficiently ensure that users only access data relevant to their -role, enhancing security and minimizing risks. +**Role-Based access control (RBAC)** simplifies data security by grouping users +into roles based on their tasks. Instead of assigning permissions to each user, +RBAC assigns privileges to roles. Users, when linked to roles, gain the +necessary access for their responsibilities. For example, in a company, a +manager's role might have different access levels than an employee's role. +Through RBAC, organizations efficiently ensure that users only access data +relevant to their role, enhancing security and minimizing risks. With role-based access control, a database administrator can assign various -privileges to roles, but for even more control over who can access certain -data, Memgraph Enterprise offers [fine-grained access -control](#fine-grained-access-control). Additionally, you can use [user profiles](/database-management/authentication-and-authorization/user-profiles) to set resource limits for users. +privileges to roles, but for even more control over who can access certain data, +Memgraph Enterprise offers [fine-grained access +control](#fine-grained-access-control). Additionally, you can use [user +profiles](/database-management/authentication-and-authorization/user-profiles) +to set resource limits for users. - -[Multi-role users and multi-tenant roles](/database-management/authentication-and-authorization/multiple-roles) for more information regarding assigning multiple roles to users or assigning roles for a specific database. - + [Multi-role users and multi-tenant +roles](/database-management/authentication-and-authorization/multiple-roles) for +more information regarding assigning multiple roles to users or assigning roles +for a specific database. ## User roles -Users can be assigned multiple roles simultaneously, with permissions from all roles being combined. User roles are abstractions -that capture the privilege levels of a set of users. +Users can be assigned multiple roles simultaneously, with permissions from all +roles being combined. User roles are abstractions that capture the privilege +levels of a set of users. -For example, suppose that `Dominik` and `Marko` belong to the upper management of a -certain company. It makes sense to grant them a set of privileges that other -users are not entitled to so, instead of granting those privileges to each of -them, we can create a role with those privileges called `manager`, which we +For example, suppose that `Dominik` and `Marko` belong to the upper management +of a certain company. It makes sense to grant them a set of privileges that +other users are not entitled to so, instead of granting those privileges to each +of them, we can create a role with those privileges called `manager`, which we assign to `Dominik` and `Marko`. In other words, each privilege that is granted to a user role is automatically -granted to all the users with that role (unless it has been explicitly denied -to that user). Similarly, each privilege that is denied to a user role is -automatically denied to all users with that role (even if it has been -explicitly granted to that user). +granted to all the users with that role (unless it has been explicitly denied to +that user). Similarly, each privilege that is denied to a user role is +automatically denied to all users with that role (even if it has been explicitly +granted to that user). -When a user has multiple roles, their permissions are combined using the following rules: +When a user has multiple roles, their permissions are combined using the +following rules: - **Grants**: If any role grants a permission, the user has that permission -- **Denies**: If any role denies a permission, the user is denied that permission -- **Database Access**: If any role grants access to a database, the user has access +- **Denies**: If any role denies a permission, the user is denied that + permission +- **Database Access**: If any role grants access to a database, the user has + access - **Fine-grained Permissions**: Combined using the same grant/deny logic To create a user role, run the following query: @@ -79,7 +86,9 @@ To show what roles a user has, run the following query: SHOW ROLE FOR user_name; ``` -**Note**: The `SHOW ROLE FOR USER` command does not require database specification, even in multi-tenant environments. It will show all roles assigned to the user across all databases. +**Note**: The `SHOW ROLE FOR USER` command does not require database +specification, even in multi-tenant environments. It will show all roles +assigned to the user across all databases. To show the current user's roles in the current session: @@ -87,7 +96,8 @@ To show the current user's roles in the current session: SHOW CURRENT ROLE; ``` -In multi-tenant environments, you can optionally specify which database context to use when showing roles: +In multi-tenant environments, you can optionally specify which database context +to use when showing roles: 1. **Show roles for the user's main database:** ```cypher @@ -104,7 +114,10 @@ SHOW ROLE FOR user_name ON CURRENT; SHOW ROLE FOR user_name ON DATABASE database_name; ``` -These commands return the aggregated roles for the user in the specified database context. The `ON MAIN` option shows roles for the user's main database, `ON CURRENT` shows roles for whatever database is currently active, and `ON DATABASE` shows roles for the explicitly specified database. +These commands return the aggregated roles for the user in the specified +database context. The `ON MAIN` option shows roles for the user's main database, +`ON CURRENT` shows roles for whatever database is currently active, and `ON +DATABASE` shows roles for the explicitly specified database. To list all defined user roles run: @@ -114,9 +127,13 @@ SHOW ROLES; ## User profiles -User profiles allow you to set resource limits for individual users to control resource consumption and prevent system abuse. +User profiles allow you to set resource limits for individual users to control +resource consumption and prevent system abuse. -For detailed information about user profiles, including profile creation, management, and advanced features, see the [User profiles](/database-management/authentication-and-authorization/user-profiles) documentation. +For detailed information about user profiles, including profile creation, +management, and advanced features, see the [User +profiles](/database-management/authentication-and-authorization/user-profiles) +documentation. ## Privileges @@ -157,9 +174,13 @@ of the following commands: -As of Memgraph v3.5 users can have different privileges on different databases. This is due to v3.5 introducing users with multiple roles and database specific roles. -All system queries (auth, replication and multi-database) now target the default "memgraph" database. Meaning that in order to execute one of these queries, a user must have the appropriate privilege AND access to "memgraph" database. -The recommendation is to use the default "memgraph" database as an admin/system database and store graphs under other databases. +As of Memgraph v3.5 users can have different privileges on different databases. +This is due to v3.5 introducing users with multiple roles and database specific +roles. All system queries (auth, replication and multi-database) now target the +default "memgraph" database. Meaning that in order to execute one of these +queries, a user must have the appropriate privilege AND access to "memgraph" +database. The recommendation is to use the default "memgraph" database as an +admin/system database and store graphs under other databases. @@ -171,11 +192,18 @@ To execute system queries (auth, replication and multi-database), users must hav ### Recommended approach for multi-tenant environments -In multi-tenant environments, we recommend treating the default "memgraph" database as an administrative/system database rather than storing application data in it. This approach provides better security and isolation: +In multi-tenant environments, we recommend treating the default "memgraph" +database as an administrative/system database rather than storing application +data in it. This approach provides better security and isolation: -1. **Restrict access to the memgraph database**: Only grant access to privileged users who need to perform authentication, authorization, replication, or multi-database management operations -2. **Use tenant-specific databases**: Store application data in dedicated tenant databases rather than the default database -3. **Separate administrative functions**: Keep user management, system administration, replication management, and multi-database management separate from application data +1. **Restrict access to the memgraph database**: Only grant access to privileged + users who need to perform authentication, authorization, replication, or + multi-database management operations +2. **Use tenant-specific databases**: Store application data in dedicated tenant + databases rather than the default database +3. **Separate administrative functions**: Keep user management, system + administration, replication management, and multi-database management + separate from application data #### Example setup for multi-tenant environments @@ -209,9 +237,12 @@ SET ROLE FOR tenant2_user_account TO tenant2_user; ``` In this setup: -- `admin_user` has access to the "memgraph" database and can perform all authentication/authorization, replication, and multi-database operations -- `tenant1_user_account` and `tenant2_user_account` can only access their respective tenant databases -- Application data is stored in tenant-specific databases, not in the default "memgraph" database +- `admin_user` has access to the "memgraph" database and can perform all + authentication/authorization, replication, and multi-database operations +- `tenant1_user_account` and `tenant2_user_account` can only access their + respective tenant databases +- Application data is stored in tenant-specific databases, not in the default + "memgraph" database After the first user is created, Memgraph will execute a query if and only if either a user or its role is granted that privilege and neither the user nor its @@ -304,9 +335,11 @@ REVOKE ALL PRIVILEGES FROM ; The user needs to reconnect to the database for the changes to take effect. - -If you get an error: `Vertex not created due to not having enough permission!` you probably need to grant the fine-grained access control to the user. -The [fine-grained access control](#fine-grained-access-control) section provides more details. + +If you get an error: `Vertex not created due to not having +enough permission!` you probably need to grant the fine-grained access control +to the user. The [fine-grained access control](#fine-grained-access-control) +section provides more details. @@ -319,7 +352,9 @@ To check privilege for a certain user or role, run the following query: SHOW PRIVILEGES FOR user_or_role; ``` -In multi-tenant environments, privileges can differ depending on the target database. The SHOW PRIVILEGE query can be expanded to show privileges on specific databases as the following: +In multi-tenant environments, privileges can differ depending on the target +database. The SHOW PRIVILEGE query can be expanded to show privileges on +specific databases as the following: 1. **Show privileges for the user's main database:** ```cypher @@ -336,11 +371,15 @@ SHOW PRIVILEGES FOR user_or_role ON CURRENT; SHOW PRIVILEGES FOR user_or_role ON DATABASE database_name; ``` -These commands return the aggregated privileges (including label-based permissions) for the user or role in the specified database context. +These commands return the aggregated privileges (including label-based +permissions) for the user or role in the specified database context. **Note**: -- For **users**: In multi-tenant environments, you must specify the database context. -- For **roles**: This command does not require database specification, even in multi-tenant environments. In which case, it will role's privileges without filtering for database. +- For **users**: In multi-tenant environments, you must specify the database + context. +- For **roles**: This command does not require database specification, even in + multi-tenant environments. In which case, it will role's privileges without + filtering for database. ## Fine-grained access control @@ -348,8 +387,8 @@ These commands return the aggregated privileges (including label-based permissio Sometimes, authorizing the database by granting and denying clause privileges is not enough to make the database fully secure. Certain nodes and relationships can be confidential and must be restricted from viewing and manipulating by -multiple users. Also, disabling users from executing certain commands is sometimes too -restrictive. +multiple users. Also, disabling users from executing certain commands is +sometimes too restrictive. In response to the need for such authorization, Memgraph has added [label-based access @@ -362,17 +401,18 @@ adequate permission. ### Label-based access control - Label-based permissions are divided into 4 hierarchical parts or levels: -- `NOTHING` - denies user visibility and manipulation over nodes and relationships +- `NOTHING` - denies user visibility and manipulation over nodes and + relationships - `READ` - grants the user visibility over nodes and relationships -- `UPDATE` - grants the user visibility and the ability to edit nodes and relationships -- `CREATE_DELETE` - grants the user visibility, editing, creation, and deletion of a node or a -relationship +- `UPDATE` - grants the user visibility and the ability to edit nodes and + relationships +- `CREATE_DELETE` - grants the user visibility, editing, creation, and deletion +of a node or a relationship #### Node permissions -Granting a certain set of node permissions can be done similarly to the clause +Granting a certain set of node permissions can be done similarly to the clause privileges using the following command: ```cypher @@ -381,17 +421,20 @@ GRANT permission_level ON LABELS label_list TO user_or_role; with the legend: - `permission_level` is either `NOTHING`, `READ`, `UPDATE` or `CREATE_DELETE` -- `label_list` is a set of node labels, separated with a comma and with a colon in front of -each label (e.g. `:L1`), or `*` for specifying all labels in the graph +- `label_list` is a set of node labels, separated with a comma and with a colon +in front of each label (e.g. `:L1`), or `*` for specifying all labels in the +graph - `user_or_role` is the already created user or role in Memgraph -For example, granting a `READ` permission on labels `L1` and `L2` would be written as: +For example, granting a `READ` permission on labels `L1` and `L2` would be +written as: ```cypher GRANT READ ON LABELS :L1, :L2 TO charlie; ``` -while granting both `READ` and `EDIT` permissions for all labels in the graph, would be written as: +while granting both `READ` and `EDIT` permissions for all labels in the graph, +would be written as: ```cypher GRANT UPDATE ON LABELS * TO charlie; @@ -405,8 +448,9 @@ GRANT NOTHING ON LABELS :L1 TO charlie; #### Relationship permissions -Relationship permission queries are in essence the same as node permission queries, with the -one difference that the name of the relationship type is `EDGE_TYPE` and not `LABEL`. +Relationship permission queries are in essence the same as node permission +queries, with the one difference that the name of the relationship type is +`EDGE_TYPE` and not `LABEL`. Granting a certain set of edge type permissions can be done similarly to the clause privileges by issuing the following command: @@ -417,7 +461,8 @@ GRANT permission_level ON EDGE_TYPES edge_type_list TO user_or_role; with the same legend as the node permissions. -For example, granting a `READ` permission on relationship type `:CONNECTS` would be written as: +For example, granting a `READ` permission on relationship type `:CONNECTS` would +be written as: ```cypher GRANT READ ON EDGE_TYPES :CONNECTS TO charlie; @@ -425,26 +470,31 @@ GRANT READ ON EDGE_TYPES :CONNECTS TO charlie; #### Revoke label-based permissions -To revoke any of the label-based permissions, users can use one of the following commands: +To revoke any of the label-based permissions, users can use one of the following +commands: ```cypher REVOKE (LABELS | EDGE_TYPES) label_or_edge_type_list FROM user_or_role ``` where: -- `label_or_edge_type_list` is a list of labels or edge types with a colon in front of each -label or edge type (or `*` for specifying all labels or edge types) +- `label_or_edge_type_list` is a list of labels or edge types with a colon in +front of each label or edge type (or `*` for specifying all labels or edge +types) - `user_or_role` is the existing user or role in Memgraph #### Show privileges for label-based access control -To check which privileges an existing user or role has in Memgraph, it is enough to write +To check which privileges an existing user or role has in Memgraph, it is enough +to write ```cypher SHOW PRIVILEGES FOR user_or_role; ``` -In multi-tenant environments, privileges can differ depending on the target database. The SHOW PRIVILEGE query can be expanded to show privileges on specific databases as the following: +In multi-tenant environments, privileges can differ depending on the target +database. The SHOW PRIVILEGE query can be expanded to show privileges on +specific databases as the following: 1. **Show privileges for the user's main database:** ```cypher @@ -461,11 +511,15 @@ SHOW PRIVILEGES FOR user_or_role ON CURRENT; SHOW PRIVILEGES FOR user_or_role ON DATABASE database_name; ``` -These commands return the aggregated privileges (including label-based permissions) for the user or role in the specified database context. +These commands return the aggregated privileges (including label-based +permissions) for the user or role in the specified database context. **Note**: -- For **users**: In multi-tenant environments, you must specify the database context. -- For **roles**: This command does not require database specification, even in multi-tenant environments. In which case, it will role's privileges without filtering for database. +- For **users**: In multi-tenant environments, you must specify the database + context. +- For **roles**: This command does not require database specification, even in + multi-tenant environments. In which case, it will role's privileges without + filtering for database. ### Templates for granting privileges @@ -500,11 +554,12 @@ GRANT READ ON EDGE_TYPES * TO readonly; Below are several examples of using the Enterprise security features. -#### Granting read permissions +#### Grant read permissions -Bob is a data analyst for the company. He is making sure he can extract any useful insights -from the data imported into the database. For now, all the data is labeled with the `DataPoint` -label. Alice has already created a data analyst role as well as Bob's account in Memgraph with: +Bob is a data analyst for the company. He is making sure he can extract any +useful insights from the data imported into the database. For now, all the data +is labeled with the `DataPoint` label. Alice has already created a data analyst +role as well as Bob's account in Memgraph with: ```cypher CREATE ROLE analyst; @@ -575,7 +630,7 @@ approach is called whitelisting, and is more secure for adding new entities in the database since confidential nodes and relationships are not leaked into the database before securing them. -#### Granting update permissions +#### Grant update permissions Charlie is a tester and customer care specialist. He is in charge of reporting bugs and fixing issues in the database. A common problem that he is facing is @@ -618,7 +673,7 @@ Charlie is now able to update the labeled categories of any data point in the graph! The same permission applies if he needs to update a relationship property in the graph. -#### Granting full access permissions +#### Grant full access permissions David is the data engineer for the company. He is very skilled in database systems, and he has been assigned the task of deleting every data point in the @@ -637,8 +692,8 @@ GRANT UPDATE ON LABELS :DataPoint TO dataEngineer; GRANT UPDATE ON EDGE_TYPES :NEXT TO dataEngineer; ``` -However, `UPDATE` privilege capabilities only grant manipulation of properties, not the nodes -and relationships themselves. Therefore, the query: +However, `UPDATE` privilege capabilities only grant manipulation of properties, +not the nodes and relationships themselves. Therefore, the query: ```cypher MATCH (n:DataPoint) WHERE localDateTime() - n.date > Duration({day:365}) DETACH DELETE n; @@ -657,7 +712,7 @@ The permission is executed on relationships as well, since David needs to detach the nodes prior to deleting them. David is now able to successfully delete the deprecated nodes. -#### Denying visibility +#### Deny visibility Eve is the new senior engineer, and she is making excellent progress in the company. The management therefore decided to grant her visibility and