POST_START

Performing a Production Unity Catalog Authorization Review

I was tasked with reviewing the authorization settings for the production catalog in our Unity Catalog environment. This was part of a routine security audit to ensure that only the right users had access to the right resources. I started by checking the grants at the catalog level to get an overview of who had permissions and what they could do.

SHOW GRANTS ON CATALOG production;

I saw a representative result like this:

principal	actionType	objectType
data_analysts	USE CATALOG	CATALOG
data_engineers	CREATE SCHEMA	CATALOG

This showed that the data_analysts group had the USE CATALOG permission, allowing them to access the catalog, while the data_engineers group had the CREATE SCHEMA permission, which means they could create schemas within the catalog. I noted that these permissions aligned with our team’s roles, but I wanted to dig deeper into the schemas and objects within the production catalog.

I next checked the sales schema within the production catalog to see what permissions were assigned there.

SHOW GRANTS ON SCHEMA production.sales;

I saw a representative result like this:

principal	actionType	objectType
data_analysts	USE SCHEMA	SCHEMA
data_engineers	CREATE TABLE	SCHEMA

This showed that the data_analysts group had the USE SCHEMA permission, allowing them to access the sales schema, while the data_engineers group had the CREATE TABLE permission, which would enable them to create tables within the schema. I realized this was a common pattern across the catalog, where different groups had access to different levels of resources based on their responsibilities.

To ensure that the data access was properly scoped, I then checked the orders table within the sales schema.

SHOW GRANTS ON TABLE production.sales.orders;

I saw a representative result like this:

principal	actionType	objectType
data_analysts	SELECT	TABLE
data_engineers	MODIFY	TABLE

This was a critical point in the review. The data_analysts group had the SELECT permission, which allowed them to query the data, while the data_engineers group had the MODIFY permission, which meant they could alter or update the data. I verified that this setup was appropriate for the team’s workflow, as analysts needed read access, while engineers required write access for data maintenance.

Next, I wanted to check the documents volume in the files schema, since volumes are used for storing unstructured data like documents and files.

SHOW GRANTS ON VOLUME production.files.documents;

I saw a representative result like this:

principal	actionType	objectType
data_engineers	READ VOLUME	VOLUME
data_engineers	WRITE VOLUME	VOLUME

This showed that the data_engineers group had both READ VOLUME and WRITE VOLUME permissions. I confirmed that this was intentional, as the volume was used for storing files that needed to be accessed and modified by the engineering team. No other groups had access to the volume, which was good from a security standpoint.

Finally, I reviewed the production_raw external location, which was used to access raw data from external systems.

SHOW GRANTS ON EXTERNAL LOCATION production_raw;

I saw a representative result like this:

principal	actionType	objectType
data_analysts	USE CATALOG	CATALOG
data_engineers	USE CATALOG	CATALOG

This indicated that both data_analysts and data_engineers had the USE CATALOG permission for the production catalog. This was expected, as both groups needed to access the catalog to work with the data. I made a note that the USE CATALOG permission was necessary for accessing external locations, which were part of the production environment.

After reviewing all the grants, I felt confident that the access controls were aligned with our team’s needs and security requirements. I documented the findings and shared them with the security team for further review and validation.