Managing Object Permissions in Unity Catalog

1. The Unity Catalog Security Model

Effective permission management starts with understanding three core components:

1. Principals: The "who." These are the identities that permissions are granted to. In Unity Catalog, this includes:

   • Users: Individual user accounts (e.g., user@company.com).
   • Service Principals: Identities for automated jobs and services, which you'll use for production workflows.
   • Groups: Collections of users and/or service principals (e.g., data_analysts, data_engineers). Using groups is the recommended best practice for scalable governance.

2. Securable Objects: The "what." These are the assets in Unity Catalog that you can grant privileges on. They exist in a clear hierarchy, which you're already familiar with.

3. Privileges: The "how." These define the specific actions a principal can perform on an object (e.g., SELECT to read data, MODIFY to change data).

To get a quick overview of these concepts, please watch the first part of the following video.

2. The Privilege Inheritance Model

Unity Catalog's power comes from its hierarchical inheritance model. Privileges granted on a parent object are inherited by its child objects.

• If you GRANT SELECT ON a_schema to a group, that group can select from all current and future tables and views within that schema.
• If you GRANT SELECT ON a_catalog to a group, that group can select from all tables and views in all schemas within that catalog.

This allows you to set broad permissions at a high level (a "top-down" approach) or fine-grained permissions at a low level (a "bottom-up" approach).

The USAGE Privilege: A Critical Exception

There's one crucial exception to inheritance that is a frequent source of confusion and a common topic on certification exams. To access an object within a catalog or schema, a principal must have the USE CATALOG privilege on the parent catalog AND the USE SCHEMA privilege on the parent schema.

• These USAGE privileges are not inherited.
• Granting SELECT on a table is useless if the principal doesn't also have USAGE on the parent schema and catalog.

Think of it like a keycard system. You need a keycard for the building (USE CATALOG) and a keycard for the correct floor (USE SCHEMA) before you can even try to open the door to a specific room (SELECT on a table).

3. Granting and Revoking Permissions with SQL

As a data engineer, you will primarily manage permissions programmatically using SQL. The core commands are GRANT and REVOKE.

The general syntax is:
GRANT <privilege(s)> ON <securable_object_type> <object_name> TO <principal>;
REVOKE <privilege(s)> ON <securable_object_type> <object_name> FROM <principal>;

Let's walk through a practical scenario. Imagine you have two groups: data_analysts and data_engineers. You want to give analysts read-only access to a table, and engineers read-write access.

We will use the catalog you created in the previous lesson, dce_pro_practice.

Step 1: Grant USAGE on the Catalog and Schema

First, both groups need access to the building and the floor.

-- Assume you are a metastore admin or the owner of the catalog.
-- First, grant access to the catalog
GRANT USE CATALOG ON CATALOG dce_pro_practice TO `data_analysts`;
GRANT USE CATALOG ON CATALOG dce_pro_practice TO `data_engineers`;

-- Next, grant access to the schema within that catalog
GRANT USE SCHEMA ON SCHEMA dce_pro_practice.bronze_layer TO `data_analysts`;
GRANT USE SCHEMA ON SCHEMA dce_pro_practice.bronze_layer TO `data_engineers`;

Step 2: Grant Table-Level Privileges

Now that they can get to the table, we grant the specific data access privileges.

-- Grant read-only access to the analysts
GRANT SELECT ON TABLE dce_pro_practice.bronze_layer.customers TO `data_analysts`;

-- Grant read and write access to the engineers
-- The MODIFY privilege includes INSERT, UPDATE, DELETE, and MERGE operations.
GRANT SELECT, MODIFY ON TABLE dce_pro_practice.bronze_layer.customers TO `data_engineers`;

To see this entire process in action, including what happens when a user lacks the necessary USAGE privileges, the following video demonstration is extremely helpful.

4. Auditing Permissions and Best Practices

A core part of governance is being able to answer the question, "Who has access to what?" The SHOW GRANTS command is your tool for auditing.

-- Show all grants on a specific table
SHOW GRANTS ON TABLE dce_pro_practice.bronze_layer.customers;

-- Show all grants given to a specific group
SHOW GRANTS FOR `data_analysts`;

Building a secure and maintainable data platform requires more than just knowing the syntax. It requires adopting strong governance patterns.

The most important best practice from that article, and for your professional work, is: Always assign permissions to groups, not individual users. Managing permissions for a handful of role-based groups (e.g., finance_analysts, marketing_bi, data_engineers) is far more scalable than managing them for hundreds of individual users. When a person's role changes, you simply move them to a different group, and their permissions update automatically.

Conclusion

In this lesson, you have learned the essential mechanisms for securing data within the Databricks Lakehouse Platform. You can now control precisely who can access which data and what they are allowed to do with it.

Key Takeaways:

• The Unity Catalog security model is based on principals, securable objects, and privileges.
• Privileges are inherited down the object hierarchy, from catalog to schema to table.
• The USE CATALOG and USE SCHEMA privileges are mandatory prerequisites for accessing any object within them and are not inherited.
• You can manage permissions programmatically using GRANT, REVOKE, and SHOW GRANTS SQL commands.
• The most critical best practice for scalable governance is to grant permissions to groups, not individual users, and to adhere to the principle of least privilege.

Preview of the Next Lesson:

So far, we've focused on securing objects within Unity Catalog's metadata layer. But where is the actual data stored? In your cloud provider's storage (e.g., AWS S3, Azure Data Lake Storage). In the next lesson, we will configure external locations and storage credentials for managed data access. This will connect the logical world of Unity Catalog to the physical world of cloud storage, allowing you to govern data that lives outside of the default Databricks-managed buckets.