POST_START

Removing Production Unity Catalog RBAC Privileges During User or Team Offboarding

I recently had to handle the offboarding of a data engineering team from our production environment. One of the critical steps in this process was ensuring that all team members no longer had access to sensitive data and systems. As part of the security and compliance protocols, I needed to remove their RBAC privileges in Unity Catalog. This was especially important for the production.sales.orders table, which contained critical business data that should only be accessible to authorized personnel.

I started by recalling the roles and permissions that were granted to the data_engineers team. I knew that the MODIFY privilege on the production.sales.orders table allowed them to both read and write data, which was no longer appropriate after their offboarding. My first step was to check what privileges were currently assigned to this table.

Checking Current Privileges

I ran the SHOW GRANTS ON TABLE production.sales.orders; command to get a clear view of the current access rights. This step was crucial because it helped me confirm exactly what permissions were in place and ensured I didn’t inadvertently revoke something that wasn’t supposed to be revoked.

SHOW GRANTS ON TABLE production.sales.orders;

The output showed that the data_engineers team had both SELECT and MODIFY privileges on the table. This confirmed that I needed to remove both privileges to ensure that the team no longer had access to the data.

Revoking MODIFY Privileges

Next, I decided to start with the MODIFY privilege. I ran the following command to revoke it from the data_engineers team:

REVOKE MODIFY ON TABLE production.sales.orders FROM `data_engineers`;

I chose to revoke MODIFY first because it’s a more powerful privilege than SELECT—it includes the ability to read and write data. By revoking MODIFY, I effectively removed both the write and read capabilities. However, I wanted to be thorough and make sure that no additional access was retained, so I proceeded to revoke the SELECT privilege as well.

Revoking SELECT Privileges

I then executed the command to revoke the SELECT privilege on the same table:

REVOKE SELECT ON TABLE production.sales.orders FROM `data_engineers`;

This step ensured that even if the MODIFY privilege was somehow retained, the team would no longer have the ability to read the data. It was a redundant check, but in a production environment, it’s better to be safe than sorry.

Verifying the Changes

To confirm that the privileges had been successfully revoked, I re-ran the SHOW GRANTS command. This time, the output showed that neither the SELECT nor the MODIFY privileges were assigned to the data_engineers team. This verification was essential to ensure that the offboarding process was complete and that the data remained secure.

I also reviewed the Unity Catalog UI to cross-check the changes. The UI provided a visual confirmation that the team had been removed from the table’s access list. This step gave me confidence that the changes were reflected across all systems and that the data was protected.

Conclusion

By following these steps, I was able to securely remove the data_engineers team’s access to the production.sales.orders table. This process reinforced the importance of RBAC management during user or team offboarding. It’s a critical part of maintaining data security and compliance in a production environment. I learned that even small oversights in access management can lead to significant risks, so it’s always better to be thorough and methodical in these tasks.