# Immuta Integrations Immuta does not require users to learn a new API or language to access protected data. Instead, Immuta integrates with existing tools and ongoing work while remaining invisible to downstream consumers. The following data platforms integrate with Immuta: * [**Snowflake integration**](https://documentation.immuta.com/2024.2/data-and-integrations/snowflake/snowflake): With this integration, policies administered in Immuta are pushed down into Snowflake as [Snowflake governance features](https://docs.snowflake.com/en/user-guide/admin-governance.html) (row access policies and masking policies). * **Databricks**: * [**Databricks Unity Catalog integration**](https://documentation.immuta.com/2024.2/data-and-integrations/databricks-unity-catalog/unity-catalog): 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. * [**Databricks Spark integration**](https://documentation.immuta.com/2024.2/data-and-integrations/databricks-spark/reference-guides/databricks): 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. * [**Google BigQuery**](https://documentation.immuta.com/2024.2/google-bigquery#overview): In this integration, Immuta generates policy-enforced views in your configured Google BigQuery dataset for tables registered as Immuta data sources. * [**Starburst (Trino) integration**](https://documentation.immuta.com/2024.2/data-and-integrations/starburst-trino/trino): The Starburst (Trino) integration allows you to access policy-protected data directly in your Starburst (Trino) catalogs without rewriting queries or changing your workflows. Immuta policies are translated into Starburst (Trino) rules and permissions and applied directly to tables within users’ existing catalogs. * [**Redshift integration**](https://documentation.immuta.com/2024.2/data-and-integrations/redshift/redshift): 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. * [**Azure Synapse Analytics integration**](https://documentation.immuta.com/2024.2/data-and-integrations/azure-synapse-analytics/synapse): 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. * [**Amazon S3 integration**](https://documentation.immuta.com/2024.2/data-and-integrations/amazon-s3): The Amazon S3 integration allows users to apply subscription policies to data in S3 to restrict what prefixes, buckets, or objects users can access. To enforce access controls on this data, Immuta creates S3 grants that are administered by S3 Access Grants, an AWS feature that defines access permissions to data in S3. ## Feature support The table below outlines the features supported by each of Immuta's integrations.

	Project workspaces	Tag ingestion	User impersonation	Query audit	Multiple integrations
Snowflake	✅	✅	✅	✅	✅
Databricks Unity Catalog	❌	✅	❌	✅	✅
Databricks Spark	✅	❌	✅	✅	✅
Google BigQuery	❌	❌	❌	❌	❌
Starburst	❌	❌	✅	✅	✅
Redshift	❌	❌	✅	❌	✅
Azure Synapse Analytics	❌	❌	✅	❌	✅
Amazon S3	❌	❌	❌	❌	✅

## Policy support 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 or constant policies. * On Starburst data sources, the `@iam` interpolation function can block the creation of a view. For details about each of these policies, see the [Policies in Immuta page](https://documentation.immuta.com/2024.2/secure-your-data/authoring-policies-in-secure/policies-explained). ## Audit support for platform queries The table below outlines what information is included in the query audit logs for each integration where query audit is supported.

	Snowflake	Databricks Spark	Databricks Unity Catalog	Starburst (Trino)
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	✅	✅	Limited support	✅
Columns returned	✅	❌	❌	✅
Query text	✅	✅	Limited support	✅
Unauthorized information	Limited support	✅	Limited support	❌
Policy details	❌	✅	❌	❌
User's entitlements	❌	✅	❌	❌
Column tags	✅	❌	❌	✅
Table tags	✅	❌	❌	❌

**Legend**: * :white\_check\_mark: This is available and the information is included in audit logs. * :x: This is not available and the information is not included in audit logs. [^1]: For some queries, Databricks Unity Catalog does not report the target data source for the data access operation. In these cases the activity is audited, yet the audit record in Immuta will not include the target data source information. [^2]: Audit will return the `commandText` which often shows the query made. [^3]: Unauthorized information is only available when the integration has table replacements enabled. [^4]: Unauthorized queries will be audited when available.