Table-level permissions
Fluss supports table-level permission control. You can assign a role to a specific table to achieve fine-grained access management. For example, when multiple teams share the same database, you can restrict each team to only the tables that it owns.
Table-level authorization
By default, after you grant a user a role on a database, the user can operate on all tables in the database. If you want a user to access only some of the tables, use table-level authorization.
Table-level authorization assigns a user a role on a specific table. For a table that has a table-level role, the effective permission is the higher of the database-level and table-level roles. For a table without a table-level role, the database-level role applies.
Table-level and database-level permissions are configured independently and do not constrain each other. The effective permission on a table is the higher of the database-level and table-level roles. For example, if a user has the database-level Viewer role (read-only), you can assign the Writer role on a specific table (the effective permission is read/write), or assign the Viewer role (the effective permission remains read-only). If a user is not granted a database-level role, you can grant any table-level role separately.
Roles
|
Role |
Description |
|
Admin |
Manage table schemas (create, modify, and delete tables), read and write data, and manage authorization. |
|
Developer |
Manage table schemas (create, modify, and delete tables), and read and write data. |
|
Writer |
Read and write data. |
|
Viewer |
Query data only (read-only). |
Prerequisites
-
A Fluss cluster of version 0.9-ali-5.0 or later is created.
-
A database and tables are created.
-
The target user is created in Fluss Manager.
-
You have the Admin role on the target database. Only the Admin role can manage table-level permissions, including adding, modifying, and removing them.
Make table-level permissions take effect in deployments
After you configure table-level permissions, the Flink deployment must pass the operator identity to Fluss for authentication. Otherwise, the table-level permissions do not take effect. To use table-level permissions on Alibaba Cloud Flink, all of the following conditions must be met:
-
Fluss cluster version: The cluster version is 0.9-ali-5.0 or later, and table-level permissions are configured for the target table on the Fluss cluster.
-
Flink engine version: The Flink engine version used by the deployment, that is, the Ververica Runtime (VVR) version of Realtime Compute for Apache Flink, must be 11.8.0 or later. Deployments that use an earlier version do not support identity passing, and table-level permissions cannot take effect.
-
Fluss catalog: You must create a new Fluss catalog to support authentication based on identity passing. A newly created catalog supports identity passing by default. For more information, see Manage Fluss catalogs.
Fluss versions earlier than 0.9-ali-5.0 do not support table-level permissions, and users read and write data by using the administrator account and password. To avoid affecting existing workloads, create a new Fluss catalog on Flink for table-level permission management instead of modifying an existing catalog.
Migration of existing deployments: To enable table-level permissions for existing deployments, perform both of the following operations:
-
Upgrade the Flink version to VVR 11.8.0 or later.
-
In the deployment SQL, change the Fluss catalog to the newly created catalog that supports identity passing, and then restart the deployment for the change to take effect.
Deployments that do not yet meet the preceding conditions continue to run as expected, but table-level permissions do not take effect for them.
Other compute engines, such as Spark and StarRocks, will support identity passing and table-level permissions in later versions.
Procedure
Grant table-level permissions to a user
-
Log on to the Realtime Compute console and go to the Fluss Manager console.
-
In the left-side navigation pane, choose Security > Authorization.
-
Click the Authorization > Table Authorization tab.
-
Click Add Authorization.
-
In the dialog box, select the database, table, user, and role.
-
Click OK.
View the effective permissions of a user
-
In the left-side navigation pane, choose Security > Authorization, click the Members tab, and then click the target user to go to the details page.
-
Click the Table Permissions tab to view the permissions of the user on each table and the source of each permission.
|
Database |
Table |
Effective role |
Permission source |
|
dw_realtime |
order_stream |
Developer |
Table-level authorization |
|
dw_realtime |
user_behavior |
Writer |
Inherited from the database |
|
dw_realtime |
risk_events |
Writer |
Table-level authorization (the higher database-level role applies) |
Modify table-level permissions
-
On the Table Authorization tab, find the target record and click Edit.
-
Modify the role and click OK.
Remove table-level permissions
-
On the Table Authorization tab, find the target record and click Remove.
-
Confirm the removal.
After the removal, the permissions of the user on the table revert to the inherited database-level permissions. If the user has no database-level permissions, the user cannot access the table.
Scenarios
Multiple teams share a database
A company has tables for both the risk control team and the recommendation team in the dw_realtime database. The risk control team needs to read from and write to only the risk_events table, and the recommendation team needs to read from and write to only the user_behavior and item_features tables.
Use table-level authorization: Do not grant database-level permissions. Grant each team the Writer role only on its own tables. Each team can access only its own tables without affecting the other.
Elevate permissions on a specific table
By default, the data analyst team has the Viewer role (read-only) on the database. One senior analyst needs read and write permissions on the user_behavior table.
Use table-level authorization: Keep the database-level Viewer role unchanged and assign the Writer role to the analyst on the user_behavior table only. The analyst retains read-only access to other tables and gains read and write permissions on the user_behavior table.
FAQ
Can a table-level permission be lower than the database-level permission?
Yes, you can configure it. Table-level and database-level permissions are configured independently and do not constrain each other. However, if the table-level permission is lower than the database-level permission, the effective permission is still the database-level permission because the higher one applies. For example, if a user has the database-level Writer role and you set the Viewer role on a table, the effective permission on that table is still Writer. Restricting specific operations on a specific table, such as prohibiting table deletion, will be supported in later versions.
Can table-level permissions be granted separately to a user who has no database-level permissions?
Yes. You can grant a user permissions on a specific table without granting database-level permissions first. This is suitable for external consumers that need to access only one table.
Do configured table-level permissions remain valid after database-level permissions are deleted?
Yes. Table-level permissions are independent. Deleting database-level permissions does not affect configured table-level permissions.
Why can a deployment still access all tables after table-level permissions are configured?
Table-level permissions require support on the deployment side to take effect. A deployment that uses an earlier catalog reads and writes data by using the administrator account, bypasses table-level permission authentication, and is therefore not restricted. Check the following three items:
-
Fluss cluster configuration: Make sure that table-level permissions are configured and saved for the target table on the Fluss cluster.
-
Flink version: Check whether the deployment uses VVR 11.8.0 or later. Deployments that use an earlier version do not support identity passing, and table-level permissions do not take effect.
-
Fluss catalog: Check whether a new Fluss catalog is created. Earlier catalogs do not support identity passing. You must create a new catalog for the permissions to take effect.
What do I do if an error occurs when an earlier Flink deployment uses a password-free Fluss catalog?
A password-free catalog is a catalog connection method in earlier Fluss versions that automatically authenticates by using the administrator account without a username or password. After a Fluss cluster is upgraded to 0.9-ali-5.0 or later, such earlier password-free catalogs may report errors because the authentication mechanism has changed.
Solution: Upgrade the Flink deployment to VVR 11.8.0 or later and re-create the Fluss catalog to support authentication based on identity passing. For more information, see Make table-level permissions take effect in deployments.
Does modifying a database-level role affect table-level permissions?
No. Table-level and database-level permissions are configured independently. Modifying a database-level role does not affect configured table-level permissions and does not trigger a conflict prompt. After the modification, the effective permission is automatically recalculated as the higher of the database-level and table-level roles. For information about how to manage database-level roles, see Grant access to a Fluss cluster.