Integrations Overview
Immuta does not require users to learn a new API or language to access data exposed there. Instead, Immuta integrates with existing tools and ongoing work while remaining invisible to downstream consumers. This page outlines those integrations.
The Snowflake integration differs based on your Snowflake Edition:
Snowflake Integration Using Snowflake Governance Features: With this integration, policies administered in Immuta are pushed down into Snowflake as Snowflake governance features (row access policies and masking policies). This integration requires Snowflake Enterprise Edition or higher.
Snowflake Integration Without Snowflake Governance Features: With this integration, policies administered by Immuta are pushed down into Snowflake as views with a 1-to-1 relationship to the original table and all policy logic is contained in that view.
Click a link below for details about each question:
This integration allows you to manage multiple Databricks workspaces through Unity Catalog while protecting your data with Immuta policies. Instead of manually creating UDFs or granting access to each table in Databricks, you can author your policies in Immuta and have Immuta manage and enforce Unity Catalog access-control policies on your data in Databricks clusters or SQL warehouse.
Immuta’s Databricks Spark integration with Unity Catalog support uses a custom Databricks plugin to enforce Immuta policies on a Databricks cluster with Unity Catalog enabled. This integration allows you to add your tables to the Unity Catalog metastore so that you can use the metastore from any workspace while protecting your data with Immuta policies.
This integration enforces policies on Databricks tables registered as data sources in Immuta, allowing users to query policy-enforced data on Databricks clusters (including job clusters). Immuta policies are applied to the plan that Spark builds for users' queries, all executed directly against Databricks tables.
Deprecation notice
Support for this integration has been deprecated. Use the Starburst (Trino) v2.0 integration instead.
The Starburst (Trino) integration enables Immuta to apply policies directly in Starburst and Trino clusters without going through a proxy. This means users can use their existing Starburst and Trino tooling (querying, reporting, etc.) and have per-user policies dynamically applied at query time.
The Starburst (Trino) integration v2.0 allows you to access policy-protected data directly in your Starburst (Trino) catalogs without rewriting queries or changing your workflows. Instead of generating policy-enforced views and adding them to an Immuta catalog that users have to query (like in the legacy Starburst (Trino) integration), Immuta policies are translated into Starburst (Trino) rules and permissions and applied directly to tables within users’ existing catalogs.
With the Redshift integration, Immuta applies policies directly in Redshift. This allows data analysts to query their data directly in Redshift instead of going through a proxy.
The Azure Synapse Analytics integration allows Immuta to apply policies directly in Azure Synapse Analytics dedicated SQL pools without needing users to go through a proxy. Instead, users can work within their existing Synapse Studio and have per-user policies dynamically applied at query time.
Private preview
This integration is available to select accounts. Reach out to your Immuta representative for details.
In this integration, Immuta generates policy-enforced views in your configured Google BigQuery dataset for tables registered as Immuta data sources.
External Catalogs
Users who want to use tagging capabilities outside of Immuta and pull tags from external table schemas can connect Collibra or Alation as an external catalog. Once they have been connected, Immuta will ingest a data dictionary from the catalog that will apply data source and column tags directly onto queryable data sources. These tags can then be used to write and drive policies.
If users have another catalog, or have customized their Collibra or Alation integrations, they can connection through the REST Catalog using the Immuta API.
Users can also connect a Snowflake account to allow Immuta to ingest Snowflake tags onto Snowflake data sources.
External IAMs
External identity managers configured in Immuta allow users to authenticate using an existing identity management system and can optionally be used to synchronize user groups and attributes into Immuta.
Feature, Audit, and Policy Support
Feature Support
The table below outlines the features supported by each of Immuta's integrations.
| Project Workspaces | Tag Ingestion | User Impersonation | Native Query Audit | Multiple Integrations | |
|---|---|---|---|---|---|
Snowflake | ✅ | ✅ | ✅ | ✅ | ✅ |
Databricks Unity Catalog | ❌ | ❌ | ❌ | ✅ | ✅ |
Databricks Spark | ✅ | ❌ | ✅ | ✅ | ✅ |
Databricks SQL | ❌ | ❌ | ❌ | ❌ | ✅ |
Starburst (Trino) | ❌ | ❌ | ✅ | ✅ | ✅ |
Redshift | ❌ | ❌ | ✅ | ❌ | ✅ |
Azure Synapse Analytics | ❌ | ❌ | ✅ | ❌ | ✅ |
Audit Support Matrix
The table below outlines the audit support by each of Immuta's integrations and what information is included in the audit logs.
| Snowflake | Databricks Spark | Databricks Unity Catalog | Starburst (Trino) | Redshift | Azure Synapse Analytics | |
|---|---|---|---|---|---|---|
Native query audit type | Legacy audit and UAM | Legacy audit and UAM | Legacy audit and UAM | Legacy audit | ❌ | ❌ |
Table and user coverage | Registered data sources and users | Registered data sources and users | All tables and users | Registered data sources and users | ❌ | ❌ |
Object queried | ✅ | ✅ | ✅ | ❌ | ❌ | |
Columns returned | ✅ | ❌ | ❌ | ❌ | ❌ | |
Query text | ✅ | ✅ | ✅ | ❌ | ❌ | |
Unauthorized information | ✅ | ❌ | ❌ | ❌ | ||
Policy details | ❌ | ✅ | ❌ | ❌ | ❌ | |
User's entitlements | ❌ | ✅ | ❌ | ❌ | ❌ |
Legend:
✅ This is available and the information is included in audit logs.
❌ This is not available and the information is not included in audit logs.
Policy Support Matrix
Certain policies are unsupported or supported with caveats, depending on the integration:
*Supported with Caveats:
On Databricks data sources, joins will not be allowed on data protected with replace with NULL/constant policies.
On Trino data sources, the Immuta functions
@iamand@interpolatedComparisonfor WHERE clause policies can block the creation of views.
For details about each of these policies, see the Policies in Immuta page.
Last updated
