Migrating to Access Control
This functionality is for Dremio v16.0+ Enterprise Edition only.
Regardless of whether specific users at your organization had the CREATE TABLE and DROP privileges previously, after upgrading to Dremio v16.0+ ALL USERS will now have this privilege. We recommend that you re-assign these privileges to users as needed once this process is complete.
Organizations upgrading from a previous version of Dremio to v16.0+ will undergo an upgrade process wherein all privileges for your existing objects is translated to the new access control functionality. This means that privileges you’ve previously assigned to users and groups will be updated with new privileges and associated values.
The process of upgrading is seamless, meaning that once a company has upgraded to version v16.0+ of Dremio, then existing privileges will automatically translate to the new access control functionality.
During your first time accessing access control after a system upgrade, the Dremio interface may slow down temporarily as user privileges change to the new functionality.
Privilege Migration Matrix
As your Dremio application upgrades from the old system of privileges to the new access control functionality, new privileges will appear in place of the old and will have default values assigned to them. The new privileges granted automatically to users after migrating are dependent on previous privilege assignment.
The following table illustrates what the old privileges are, as well as the new ones that replace them.
| Old Privileges | New Privileges |
|---|---|
| CAN READ | SELECT |
| CAN EDIT |
|
Migration Behaviors
As a result of upgrading from the old privilege system, new privileges may or may not be assigned to users or groups depending on their previous access. The following sections break down the conditions that determine what privileges are assigned automatically upon migrating to the new access control functionality, and to what objects these new privileges are associated.
Combined Group Privileges Pre-Migration
Previous to Dremio 16.0, it was possible for a user to receive access to specific objects when privileges from multiple groups were leveraged. For example, User1 is a member of both GroupA, which has the CAN READ privilege for the source, and GroupB, which has the CAN EDIT privilege for that source's datasets. By being a member of each group, the combination of privileges grants User1 access to the source and its datasets.
However, upon migrating to Dremio 16.0+, User1 finds they can no longer access the datasets. This is because of the insufficient privileges held by GroupB.
Leveraging privileges from multiple groups does not function in the same way when applied to Dremio 16.0+. The Dremio service will simply see that GroupB has no access to the source, and would then refuse access to User1 when they attempt to access the datasets.
Step 1: Assign Privileges at the Dataset Level
The initial migration process removes all old privileges and assigns new ones to each user based on their current levels of access. However, as part of this step of the migration process, all privileges are removed from sources and folders/schemas and applied only at the dataset level. As a result, privileges are only assigned to existing datasets and will need to be manually assigned to any future datasets created.
The process of updating Dremio with the new access control functionality is straightforward, simply entailing that you upgrade the Dremio service.
To initiate the migration process, perform the dremio-admin upgrade command. The process will automatically take place, changing from the old to the new access control functionality.
The following examples illustrate how existing privileges are impacted by the migration process.
If you would like to retain user privileges at the folder/schema level, then we recommend also performing Step 2 of the migration process, which is outlined further below.
Example 1: CAN EDIT Folder and Datasets
user1 has the CAN EDIT privilege for FolderA and all of its contained datasets.
After migrating to the new access controls, Dremio removes all of the user's privileges from FolderA and applies the new privileges, ALTER and MANAGE GRANTS, to all existing datasets contained in FolderA.
Example 2: CAN QUERY at Source/Folder, but not Datasets
user1 has the CAN QUERY privilege for Source1 and FolderA, but not on any contained datasets.
After migrating to the new access controls, Dremio removes all of the user's privileges from Source1 and FolderA. Because no privileges were assigned to the datasets contained in FolderA, user1 does not receive the SELECT privilege for any datasets.
Example 3: CAN EDIT on a Source, CAN QUERY on a Dataset
user1 has the CAN EDIT privilege for Source1 and the CAN QUERY privilege for the dataset TableA1.
After migrating to the new access controls, Dremio removes all of the user's privileges from Source1 and only applies the new SELECT privilege to TableA1. Because the privilege associated with Source1 was not also applied specifically at the dataset level, it is not retained as part of the migration.
Example 4: No Permissions Applied
Your company has no user permissions applied at the source, folder/schema, or dataset levels.
After migrating to the new access controls, Dremio treats the absence of permissions as it would treat the PUBLIC role. As a result, all users receive the ALTER, SELECT, and MANAGE GRANTS privileges for all datasets contained in your source. All users would likewise receive the MODIFY privilege at the source level.
Step 2: Assign Privileges to the Source or Folder/Schema Levels
This second part of the migration process is done so as to also apply privileges at the source or folder/schema levels, so that user privileges are also assigned to future datasets. The command forces Dremio to examine the new privileges assigned to your datasets, and then apply privileges at the source or folder/schema level where applicable.
To initiate this step of the migration process, enter the command dremio-admin optimize-acls.
The migration process for this step examines all datasets for the same privileges. If each dataset contains the same privilege for a user, then the privilege is removed from the dataset and applied to the parent folder. If all subfolders contain the same privilege for a user, then the privilege is moved to the parent folder. This process continues up the object hierarchy until it reaches the source level.
Unless the same privileges for a user are assigned to all datasets in a folder, this step of the migration process will not apply the privilege to the source or folder levels. Even if a user lacks privileges for a single dataset, privileges cannot be assigned at a higher level.
Example 1: All Datasets in a Folder
user1 has the SELECT privilege for all datasets in FolderA.
After performing this step of the migration process, Dremio checks all datasets to ensure the same privileges are found for user1 in each folder. Because all datasets in FolderA have the same privilege assigned, Dremio then changes these objects. The privileges are removed from the individual datasets and then applied instead to FolderA. Due to the rules of inheritance, all existing and future datasets contained in their parent folder, FolderA, must treat user1 as having the SELECT privilege.
Example 2: All Subfolders
user1 has the SELECT privilege for all subfolders in Folder1.
The migration process has already gone through each subfolder and found that all of their contained datasets contained the SELECT privilege for user1, so now the privilege is applied at the subfolder level. Now all subfolders in Folder1 have the same privilege assigned to the same user. Dremio then removes that privilege from each subfolder in Folder1 and applies the privilege to the parent folder. By the rules of inheritance, all existing or future subfolders and datasets will treat user1 as having the SELECT privilege.
Example 3: All Folders in a Source
user1 has the SELECT privilege for all parent folders in Source1.
The migration process has already gone through each dataset and subfolder and found that all contained objects have the SELECT privilege assigned to user1, so now the privilege is applied at the parent folder level. Now all parent folders in Source1 have the same privilege assigned to the same user. Dremio then removes that privilege from each parent folder in Source1 and applies the privilege to the source. By the rules of inheritance, all existing or future parent folders, subfolders, and datasets will treat user1 as having the SELECT privilege.
