POST_START
Removing Legacy Direct Access After an RBAC Migration
I recently completed a migration from a legacy access model to a more secure and scalable Role-Based Access Control (RBAC) system in Databricks Unity Catalog. One of the critical steps in this process was removing direct access permissions that were no longer needed after the migration. I needed to ensure that all users who previously had direct access to the production.sales.orders table were now governed by role-based policies.
Checking Current Permissions
I started by checking the current permissions on the production.sales.orders table to understand what access was in place before the migration. This was important to confirm that the legacy roles were still present and to verify the exact permissions that needed to be revoked.
SHOW GRANTS ON TABLE production.sales.orders;
| principal | actionType | objectType |
|---|---|---|
| data_analysts | SELECT | TABLE |
| data_engineers | MODIFY | TABLE |
I noticed that the data_analysts role had SELECT access, and the data_engineers role had MODIFY access. However, these roles were part of the new RBAC system, and I needed to remove the legacy direct access that was still in place for some users.
Revoking Legacy Access
Next, I identified the legacy role that had been used previously, which was legacy_analysts. This role had direct access to the table, which was no longer aligned with the new RBAC model. I decided to revoke the SELECT privilege from this role to ensure that access was fully transitioned to the new roles.
REVOKE SELECT ON TABLE production.sales.orders FROM `legacy_analysts`;
Revoke applied successfully; the requested privilege is no longer granted.
I verified that the privilege had been successfully revoked. It was important to make sure that no lingering access remained, especially since the legacy role might have been used by multiple users or systems that were no longer active.
Verifying the Changes
To confirm that the changes had taken effect, I ran the SHOW GRANTS command again. This helped me ensure that the legacy access had been fully removed and that the new roles were the only ones with access to the table.
SHOW GRANTS ON TABLE production.sales.orders;
| principal | actionType | objectType |
|---|---|---|
| data_analysts | SELECT | TABLE |
| data_engineers | MODIFY | TABLE |
I noticed that the legacy_analysts role was no longer listed, and the access remained with the new roles. This was a good sign that the migration had been successful and that the access model was now fully aligned with the RBAC system.
By following these steps, I was able to ensure a clean transition from the legacy model to the new RBAC system, reducing the risk of unauthorized access and improving the overall security posture of the data environment.
Leave a Reply