Configuring Row-level Access Control

Prerequisites

• Before creating a row-level access control policy, you have created a GaussDB(DWS) connection. For details, see Creating a Data Connection. The account in the GaussDB(DWS) connection must have the GRANT permission of the target table. (By default, only the owner of a database object or system administrator can run the GRANT command to grant the object permissions to other users.)
• Row-level access control policies need to be associated with data sources for specified users or user groups. Therefore, you need to synchronize user information from IAM to data sources first. For details, see Synchronizing Users.
• If you want to use the current user identity authentication to make row-level access control policies take effect during script execution and job tests in DataArts Factory, you need to enable permission applications by following the instructions in Enabling Permission Applications.
• To ensure that a row-level access control policy takes effect, ensure that the user specified in the policy has the permission to the table to be controlled and has the USAGE permission of the schema to which the table belongs. You can run the following commands to grant permissions to user1, user2, and user3:

  GRANT USAGE ON SCHEMA schema_name TO user1,user2,user3;
  GRANT SELECT,UPDATE,DELETE ON TABLE table_name TO user1,user2,user3;

Constraints

• Only the DAYU Administrator, Tenant Administrator, or data security administrator can create, modify, or delete row-level access control policies. Other common users do not have permission to perform these operations.
• Row-level access control policies are available for GaussDB(DWS) data sources and unavailable for GaussDB(DWS) logical clusters. The account in the GaussDB(DWS) connection must have the GRANT permission of the target table. (By default, only the owner of a database object or system administrator can run the GRANT command to grant the object permissions to other users.)
• Row-level access control policies need to be associated with data sources for specified users or user groups. Therefore, you need to synchronize user information from IAM to data sources first. For details, see Synchronizing Users.
• Row-level access control supports read operations on data tables (SELECT, UPDATE, DELETE, and ALL), and does not support write operations on data tables (INSERT and MERGE INTO).
• A row-level access control policy name is specific to a table. A data table cannot have row-level access control policies with the same name. Different data tables can have the same row-level access control policy.
• Row-level access control policies can be defined for row-store tables, row-store partitioned tables, column-store tables, column-store partitioned tables, replication tables, unlogged tables, and hash tables. Row-level access control policies cannot be defined for HDFS foreign tables or temporary tables.
• Row-level access control policies cannot be defined for views.
• A maximum of 100 row-level access control policies can be defined for a table.
• Users with GaussDB(DWS) administrator permissions and the initial O&M user (Ruby) are not affected by row-level access control. They can view all the data of a table.
• Tables queried by using SQL statements, views, functions, and stored procedures are affected by row-level access control policies.
• After a row-level access control policy is synchronized, the types of the columns on which the row-level access control policy depends cannot be changed.

Create a Row-Level Access Control Policy

1. On the DataArts Studio console, locate an instance and click Access. On the displayed page, locate a workspace and click DataArts Security.
   Figure 1 DataArts Security
   

2. In the navigation pane on the left, choose Row-Level Access Control.
   Figure 2 Row-Level Access Control page
   

3. Click Create and set the parameters listed in Table 1.
   Figure 3 Setting the parameters for creating a row-level access control policy
   
   The following table lists the parameters for creating a row-level access control policy.

   Table 1 Policy parameters

   Parameter	Description
   *Policy Name	Name of the row-level access control policy. It must be unique for a data table. To facilitate policy management, you are advised to include the target object and content rule in the name.
   *Data Source Type	Only DWS is supported.
   *Data Connection	If no data connection is available, create one by referring to Creating a Data Connection.
   *Cluster Name	You do not need to set this parameter. The data source cluster in the data connection is automatically selected.
   *Database	Database where the row is located
   *Table	Table where the row is located. After you select a table, the table structure is automatically displayed.
   *SQL Operation	Select the operation to be controlled (SELECT, UPDATE, DELETE, or ALL). Write operations including INSERT and MERGE INTO are not supported. If you select SELECT, SELECT operations will be controlled by the policy. The selected user group or user can only view the rows that meet the conditions defined by the expression. The affected operations include SELECT, UPDATE ... RETURNING, and UPDATE ... RETURNING. If you select UPDATE, UPDATE operations will be controlled by the policy. The selected user group or user can only update the rows that meet the conditions defined by the expression. The affected operations include UPDATE, UPDATE ... RETURNING, and SELECT ... FOR UPDATE/SHARE. If you select DELETE, DELETE operations will be controlled by the policy. The selected user group or user can only delete the rows that meet the conditions defined by the expression. The affected operations include DELETE and DELETE ... RETURNING.
   *User Group/User	Select the user or user group from the current workspace members. The specified user or user group can perform the selected SQL operation only on the row-level data that meets the condition defined by the expression. If you select SELECT, SELECT operations will be controlled by the policy. The selected user group or user can only view the rows that meet the conditions defined by the expression. The affected operations include SELECT, UPDATE ... RETURNING, and UPDATE ... RETURNING. If you select UPDATE, UPDATE operations will be controlled by the policy. The selected user group or user can only update the rows that meet the conditions defined by the expression. The affected operations include UPDATE, UPDATE ... RETURNING, and SELECT ... FOR UPDATE/SHARE. If you select DELETE, DELETE operations will be controlled by the policy. The selected user group or user can only delete the rows that meet the conditions defined by the expression. The affected operations include DELETE and DELETE ... RETURNING.
   *Expression	Enter the expression for determining the row data. The specified user or user group can perform the selected SQL operation only on the rows of data that meet the condition defined by the expression. The expression is in the following format: `Target field`="Operation value" You are advised to enclose target fields in backquotes and enclose operation values in double quotation marks. Use AND to combine multiple rows of data to be matched. The following is an example. `role`="test" AND `department`="sales"

4. Click Submit. After the row-level access control policy is created, click Synchronize to synchronize the policy to the data source.

Related Operations

• Synchronizing a policy: On the Row-Level Access Control page, locate a policy and click Synchronize in the Operation column to synchronize the policy to the data source. To synchronize multiple policies, select them and click Synchronize above the list.

  Policies take effect only after they are synchronized successfully. If the policy synchronization fails, you can view the policy run log in the policy details to locate the failure cause. After rectifying the fault, synchronize the policy again. If the synchronization still fails, contact technical support.

• Editing a policy: On the Row-Level Access Control page, locate a policy and click Edit in the Operation column.
• Deleting policies: On the Row-Level Access Control page, locate a policy and click Delete in the Operation column. To delete multiple policies, select them and click Delete above the list.
  

  The deletion operation cannot be undone. Exercise caution when performing this operation.

• Viewing policy details: On the Row-Level Access Control page, locate a policy and click its name to view its details.
  Figure 4 Viewing policy details