POST_START

Designing RBAC Through Catalog Schema and Table Privilege Layers

I recently had the task of setting up role-based access control (RBAC) for a new team in our organization. The goal was to ensure that the sales team could access the necessary data without exposing sensitive information. I decided to leverage Databricks Unity Catalog to design a layered access model that would grant the right level of permissions at the catalog, schema, and table levels.

Starting with Catalog-Level Access

I began by granting the `sales_readers` role access to the `production` catalog. This step was crucial because it ensured that the team could navigate to the correct data environment without unnecessary exposure to other catalogs.

GRANT USE CATALOG ON CATALOG production TO `sales_readers`;

I checked the permissions to confirm that the grant was applied successfully. This was the foundation of our access control structure. Without this, the team wouldn’t have been able to even see the catalog, let alone access its contents.

Next, Schema-Level Access

With the catalog access in place, I moved to the schema level. The sales team needed to access the `sales` schema within the `production` catalog. I granted the `USE SCHEMA` privilege on the `production.sales` schema to the `sales_readers` role.

GRANT USE SCHEMA ON SCHEMA production.sales TO `sales_readers`;

I verified that the schema-level access was granted, which allowed the team to explore the schema and its contents without exposing them to other schemas in the catalog. This step was important for maintaining data isolation and ensuring that the sales team only accessed what was necessary.

Finally, Table-Level Access

The last step was to grant the team the ability to read from the `orders` table within the `sales` schema. I used the `SELECT` privilege on the `production.sales.orders` table to ensure that the team could query the data they needed for their reports and analysis.

GRANT SELECT ON TABLE production.sales.orders TO `sales_readers`;

I ran the `SHOW GRANTS` command on the `production.sales.orders` table to verify that the permissions were correctly applied. The output confirmed that the `sales_readers` role had the `SELECT` privilege on the table, and that other roles, such as `data_analysts` and `data_engineers`, had different levels of access.

principal	actionType	objectType
data_analysts	SELECT	TABLE
data_engineers	MODIFY	TABLE

This step was critical because it ensured that the sales team could only read from the `orders` table, while other teams had more extensive permissions. This level of granularity helped us enforce the principle of least privilege and maintain data security across the organization.

Conclusion

By carefully designing the access control at the catalog, schema, and table levels, I was able to create a secure and granular RBAC model that met the needs of the sales team while protecting sensitive data. This approach not only ensured that the team had the access they needed but also helped maintain the integrity and security of our data environment.