Protecting Data

Learn how Immuta enforces policies on data in your Databricks Unity Catalog environment

In the Databricks Unity Catalog integration, Immuta administers Databricks Unity Catalog privileges on data registered in Immuta. Then, Immuta users who have been granted access to the data sources can query them.

The sequence diagram below outlines the events that occur when an Immuta user who is subscribed to a data source queries it in Databricks Unity Catalog.

Registering a connection

The Databricks Unity Catalog integration is configured and data is registered through connections, an Immuta feature that allows administrators to register data objects in a technology through a single connection to make data registration more scalable for your organization.

Once the Databricks Unity Catalog connection is registered, you can author subscription and data policies in Immuta to enforce access controls.

See the Databricks Unity Catalog integration reference guide for more details about registering a connection.

Protecting data

Subscription policies

When a subscription policy is applied to a data source, users who meet the conditions of the policy will be automatically subscribed to the data source. Immuta creates and manages Databricks Unity Catalog groups for those users (if an appropriate group does not already exist), grants the required Unity Catalog privileges to the group, and adds the entitled users to that group.

Consider the following example that illustrates how Immuta enforces a subscription policy that only allows users in the analysts group to access the yellow-table. When this policy is authored and applied to the data source, Immuta creates an Immuta-managed Databricks group (if needed), grants the SELECT privilege on yellow-table to that group, and adds users who are members of the analysts group to it.

In the image above, the user in the analysts group accesses yellow-table, while the user who is a part of the research group is denied access.

User permissions Immuta revokes

On securable objects

If you enable a Databricks Unity Catalog object in Immuta, Immuta will only manage users' access to that data object after a subscription policy grants them access to the data source. Immuta preserves all preexisting grants in Databricks and only revokes user access when explicitly dictated by an Immuta policy.

Expand the collapsible blocks below to see how Immuta-managed grants and Databricks-managed grants are affected in various scenarios.

Subscription policy applied

Immuta only manages grants for Immuta users once a subscription policy applies to them. Any grants performed on Databricks objects outside Immuta will not be revoked.

The table below illustrates how the following policy enforces access controls for 4 different users, some of whom have Databricks-managed grants:

Allow users to subscribe to the data source if they are a member of group HR

	Immuta-managed grant	Databricks-managed grant	Access result
User A - HR group	SELECT	None	✅
User B - Engineering group	None	SELECT	✅
User C	None	None	❌
User D - HR group	SELECT	SELECT	✅

In this example,

• User A is granted access to the table by Immuta.
• User B is granted access to the table by Databricks.
• User C cannot access the table because they do not meet the conditions of the Immuta policy and they have been not granted access to the table in Databricks outside of Immuta.
• User D is granted access to the table by Immuta and Databricks. The Immuta-managed SELECT grant coexists with their Databricks-managed SELECT grant.

Subscription policy edited

If a subscription policy is edited, Immuta only affects the Immuta-managed grants on the data object.

The table below illustrates how editing the following policy enforces access controls for 4 different users, some of whom have Databricks-managed grants:

Previous policy

Allow users to subscribe to the data source if they are a member of group HR

Updated policy

Allow users to subscribe if they are a member of group Engineers

	Immuta-managed grant	Databricks-managed grant	Access result
User A - HR group	Revoked	None	❌
User B - Engineering group	SELECT	SELECT	✅
User C	None	None	❌
User D - HR group	Revoked	Revoked	❌

In this example,

• User A is revoked access to the table by Immuta. Because this user was previously granted access to the data source by Immuta, that Immuta-managed grant is revoked.
• User B is granted access to the table by Databricks and Immuta. The Immuta-managed SELECT grant coexists with their Databricks-managed SELECT grant.
• User C cannot access the table because they do not meet the conditions of the Immuta policy and they have been not granted access to the table in Databricks outside of Immuta.
• User D is revoked access to the table by the change to the Immuta policy. The Immuta-managed SELECT grant (from the previous policy) and the pre-existing Databricks-managed SELECT grant have been revoked because the Immuta policy explicitly dictated that their access should be removed.

Subscription policy deleted

If a subscription policy is deleted, users' Immuta grants are revoked for that policy. Users will retain access to the data source if they have Immuta-granted access through another subscription policy that overlaps or if they have a Databricks-managed grant for that data source.

The table below illustrates how deleting the following Immuta policy affects access for 4 different users, some of whom have Databricks-managed grants:

Allow users to subscribe to the data source if they are a member of group HR

	Immuta-managed grant	Databricks-managed grant	Access result
User A - HR group	None	None	❌
User B - Engineering group	None	SELECT	✅
User C	None	None	❌
User D - HR group	None	None	❌

In this example,

• User A is revoked access to the table by Immuta. Because this user was previously granted access to the data source by Immuta, that Immuta-managed grant is revoked when the subscription policy is deleted.
• User B is granted access to the table by Databricks.
• User C cannot access the table because they have not been granted access by an Immuta policy and they have been not granted access to the table in Databricks.
• User D is revoked access to the table by Immuta. Because this user was previously granted access to the data source by Immuta, Immuta took over managing this user's grants on the table, and that Immuta-managed grant is revoked when the subscription policy is deleted.

Data source disabled

If a data source is disabled, users' access reverts to what the Databricks-managed access was previously, before the data object was registered in Immuta.

The table below illustrates how disabling the data source in Immuta affects access for 4 different users, some of whom have Databricks-managed grants.

	Immuta-managed grant	Databricks-managed grant	Access result
User A - HR group	None	None	❌
User B - Engineering group	None	SELECT	✅
User C	None	None	❌
User D - HR group	None	SELECT	✅

In this example,

• User A is revoked access to the table by Immuta. The Immuta-managed grant is revoked when the data source is disabled because the state of the grants on this data object reverts to what it was before the data object was registered in Immuta.
• User B is granted access to the table by Databricks. The Databricks-managed grant remains because the state of the grants on this data object reverts to what it was before the data object was registered in Immuta.
• User C cannot access the table because they had not been granted access to the table in Databricks.
• User D is granted access to the table by Databricks. The Immuta-managed grant is revoked and the Databricks grant remains when the data source is disabled because the state of the grants on this data object reverts to what it was before the data object was registered in Immuta.

If a user is not registered in Immuta, Immuta will have no effect on that user's access to data in Unity Catalog.

On schemas and catalogs

By default, Immuta will revoke Immuta users' USE CATALOG and USE SCHEMA privileges in Unity Catalog for users that do not have access to any of the underlying securables within that catalog/schema. If users have any Immuta-managed or Databricks-managed grants to a securable, Immuta will not revoke that catalog/schema access.

If you disable this setting, Immuta will only revoke the permissions granted on the securable objects themselves, and users' USE CATALOG and USE SCHEMA permissions will remain even if the user does not have access to any resource in that catalog/schema.

See the App settings page for instructions on changing this setting.

Data policies

After Databricks Unity Catalog objects are registered in Immuta, you can author data policies in Immuta to enforce fine-grained access controls.

When a data policy is applied to a Databricks Unity Catalog data source, Immuta enforces that policy natively in Databricks. Depending on the policy type, Immuta applies SQL user-defined functions (UDFs) to enforce row-level security and column masking on registered tables so that queries return policy-enforced results.

As data policies are created, updated, or removed in Immuta, Immuta updates the corresponding SQL UDFs in Databricks to keep enforcement in sync. Users continue querying the Databricks Unity Catalog object directly and see policy-enforced data in Databricks.

See the Data policies page for guidance on authoring data policies in Immuta and the supported data policies for the Databricks Unity Catalog integration.