What's new in Immuta

Immuta has updated the crawl logic for Databricks Unity Catalog connections in the context of workspace-bindings to better align with our policy enforcement requirements.

What’s changing

• Catalogs where the workspace associated with Immuta has read-only access.
• Isolated catalogs where Immuta cannot determine the access type: any isolated catalog where the Immuta service principal lacks MANAGE permission. This is because the Databricks API requires a service principal to have the MANAGE privilege on a catalog in order to establish its binding type (Read-only vs. Read-write). When Immuta cannot make the determination due to lack of privileges, it will be treated the same as read-only.

The treatment of unbound catalogs (i.e. catalogs accessible to all workspaces in a metastore) remains unchanged.

Impact

Policy enforcement behavior is unchanged for these catalogs: Immuta could not manage policies on them before, and still cannot. The difference is that Immuta now filters them out at the start of the ingestion process instead of ingesting them and then failing during policy enforcement.

Why this matters

Immuta cannot enforce policies or push grants on catalogs via a workspace that has read-only access, even if the Immuta service principal were given explicit privilege grants (e.g., MANAGE) on the catalog. These catalogs need to be onboarded to Immuta through a workspace holding read-write access instead.

🔎 Learn more about workspace-catalog binding in the documentation