Immuta gives everyone fast, governed access to data with the built-in controls, collaboration workflows, automated provisioning, and continuous monitoring you need to keep risk low and compliance high.

This section illustrates how to install Immuta on Kubernetes using the Immuta Enterprise Helm chart.

This reference guide provides an overview of the Immuta Enterprise Helm chart version requirements and infrastructure recommendations.

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment.

This guide illustrates how to upgrade Immuta.

The guides in this section illustrate how to configure your Immuta Enterprise Helm chart for various scenarios, including optimizing your deployment for production environments.

This guide provides links to additional resources for disaster recovery strategies.

This page provides troubleshooting guidance and outlines frequently asked questions for the Immuta installation.

This page introduces the core concepts and terminology essential for understanding the installation material.

All application state is stored in the PostgreSQL metadata database; therefore, recovering from a disaster event only entails restoring the aforementioned PostgreSQL database. Consult each cloud provider's point-in-time recovery (PITR) documentation for guidance:

• Amazon RDS for PostgreSQL

• Azure Database for PostgreSQL

• Google Cloud SQL for PostgreSQL

For more details about point-in-time recovery, see the .

In this integration, Immuta generates policy-enforced views in a schema in your configured Azure Synapse Analytics Dedicated SQL pool for tables registered as Immuta data sources.

This guide outlines how to integrate Azure Synapse Analytics with Immuta.

How-to guide

Azure Synapse Analytics configuration: Configure the integration in Immuta.

Reference guides

• Azure Synapse Analytics integration reference guide: This guide describes the design and components of the integration.

• Azure Synapse Analytics pre-configuration details: This guide describes the prerequisites, supported features, and limitations of the integration.

When you enable Unity Catalog, Immuta automatically migrates your existing Databricks data sources in Immuta to reference the legacy hive_metastore catalog to account for Unity Catalog's three-level hierarchy. New data sources will reference the Unity Catalog metastore you create and attach to your Databricks workspace.

Because the hive_metastore catalog is not managed by Unity Catalog, existing data sources in the hive_metastore cannot have Unity Catalog access controls applied to them. Data sources in the Hive Metastore must be managed by the Databricks Spark integration.

To allow Immuta to administer Unity Catalog access controls on that data, move the data to Unity Catalog and re-register those tables in Immuta by completing the steps below. If you don't move all data before configuring the integration, metastore magic will protect your existing data sources throughout the migration process.

1. Ensure that all Databricks clusters that have Immuta installed are stopped and the Immuta configuration is removed from the cluster. Immuta-specific cluster configuration is no longer needed with the Databricks Unity Catalog integration.

2. Move all data into Unity Catalog before configuring Immuta with Unity Catalog. Existing data sources will need to be re-created after they are moved to Unity Catalog and the Unity Catalog integration is configured.

3. .

Once data is registered through the Databricks Unity Catalog connection, you will access your data through your Databricks queries as you normally would. If you are subscribed to the data source, Immuta grants you access to the data in Databricks.

When you submit a query, the Databricks Unity Catalog client submits the SQL query to Databricks, which then processes the query and determines what data your group is allowed to see. Then, Databricks queries the database and returns the query results to the Databricks Unity Catalog client, which then returns policy-enforced data to you.

The diagram below illustrates how Immuta, Databricks, and Databricks Untiy Catalog client interact to access data.

Querying data

Query Databricks Unity Catalog securables exactly how you normally would in Databricks. Because grants are managed through groups and data policies are managed through UDFs, there is no additional setup required from the data consumers.

This guide demonstrates how to verify signed artifacts (i.e., container images, Helm charts) hosted on ocir.immuta.com using from .

The provided key is used to sign the Helm chart and container images.

A DIGESTS.md markdown file comes bundled in the Helm chart and contains a comprehensive list of images and digests referenced. To view the file, follow these steps:

1. Download and extract the Helm chart into the working directory.

2. Open file immuta-enterprise/DIGESTS.md

If you're using AWS OpenSearch in your Immuta installation, use this how-to to set up the proper permissions needed for username and password authentication.

1. In the AWS console, and create a master user. This user will set up the permissions for the audit user.

2. In the OpenSearch console, . This user will be the audit user. You will enter the username and password for this user when installing Immuta.

3. for the audit user.

The following conventions are used throughout the installation material.

Phrases wrapped in angle brackets (i.e., <, >) are placeholders used to indicate values that must be substituted with user-provided values. Placeholders are typically written in either , or ; the following placeholders are equivalent:

• <the-quick-brown-fox>

The how-to guides linked on this page illustrate how to integrate Azure Synapse Analytics with Immuta. See the for information about the Azure Synapse Analytics integration.

Requirement: A running Dedicated SQL pool

This integration enforces policies on Databricks securables registered in the legacy Hive metastore. Once these securables are registered as Immuta data sources, users can query policy-enforced data on Databricks clusters.

The guides in this section outline how to integrate Databricks Spark with Immuta.

This getting started guide outlines how to integrate Databricks with Immuta.

• : Manually update your cluster to reflect changes in the Immuta init script or cluster policies.

1. In the Databricks Clusters UI, install your third-party library .jar or Maven artifact with Library Source Upload, DBFS, DBFS/S3, or Maven. Alternatively, use the Databricks libraries API.

2. In the Databricks Clusters UI, add the IMMUTA_SPARK_DATABRICKS_TRUSTED_LIB_URIS

This page provides guidelines for troubleshooting issues with the Databricks Spark integration and resolving Py4J security and Databricks trusted library errors.

For easier debugging of the Databricks Spark integration, follow the recommendations below.

• Enable cluster init script logging:

  • In the cluster page in Databricks for the target cluster, navigate to Advanced Options -> Logging.

The Databricks Spark integration is one of two integrations Immuta offers for Databricks.

In this integration, Immuta installs an Immuta-maintained Spark plugin on your Databricks cluster. When a user queries data that has been registered in Immuta as a data source, the plugin injects policy logic into the plan Spark builds so that the results returned to the user only include data that specific user should see.

The reference guides in this section are written for Databricks administrators who are responsible for setting up the integration, securing Databricks clusters, and setting up users:

• : This guide includes information about what Immuta creates in your Databricks environment and securing your Databricks clusters.

In the context of the Databricks Spark integration, Immuta uses the term ephemeral to describe data sources where the associated compute resources can vary over time. This means that the compute bound to these data sources is not fixed and can change. All Databricks data sources in Immuta are ephemeral.

Ephemeral overrides are specific to each data source and user. They effectively bind cluster compute resources to a data source for a given user. Immuta uses these overrides to determine which cluster compute to use when connecting to Databricks for various maintenance operations.

The operations that use the ephemeral overrides include

• Visibility checks on the data source for a particular user. These checks assess how to apply row-level policies for specific users.

1. Navigate to the connection or connection-backed object.

2. Click Run Object Sync.

1. Click the Edit button in the Connection details box.

To delete the host,

1. Click Data in the navigation menu and select Connections.

2. Click the overflow menu in the Actions column and select Delete Host.

3. Download the cleanup script from the modal.

To delete the host,

1. Click Data in the navigation menu and select Connections.

2. Click the overflow menu in the Actions column and select Delete Connection.

3. Download the cleanup script from the modal.

To delete the host,

1. Click Data in the navigation menu and select Connections.

2. Click the overflow menu in the Actions column and select Delete Connection.

3. Click Delete Host again to confirm.

In this integration, Immuta generates policy-enforced views in your configured Redshift schema for tables registered as Immuta data sources.

This guide outlines how to integrate Redshift with Immuta.

• : Configure the integration in Immuta.

• : Configure Redshift Spectrum in Immuta.

This page outlines the configuration for setting up project UDFs, which allow users to set their current project in Immuta through Spark. For details about the specific functions available and how to use them, see the Use Project UDFs (Databricks) page.

1. Lower the web service cache timeout in Immuta:

   1. Click the App Settings icon and scroll to the HDFS Cache Settings section.

   2. Lower the Cache TTL of HDFS user names (ms) to 0.

   3. Click Save.

2. Raise the cache timeout on your Databricks cluster: In the Spark environment variables section, set the IMMUTA_CURRENT_PROJECT_CACHE_TIMEOUT_SECONDS and IMMUTA_PROJECT_CACHE_TIMEOUT_SECONDS to high values (like 10000).

   Note: These caches will be invalidated on cluster when a user calls immuta.set_current_project, so they can effectively be cached permanently on cluster to avoid periodically reaching out to the web service.

The Snowflake low row access policy mode improves query performance in Immuta's Snowflake integration by decreasing the number of Snowflake row access policies Immuta creates and by using table grants to manage user access.

Immuta manages access to Snowflake tables by administering Snowflake row access policies and column masking policies on those tables, allowing users to query them directly in Snowflake while policies are enforced.

Project-scoped purpose exceptions for Snowflake

Project-scoped purpose exceptions for Snowflake integrations allow you to apply purpose-based policies to Snowflake data sources in a project. As a result, users can only access that data when they are working within that specific project.

Masked joins for Snowflake

This feature allows masked columns to be joined across data sources that belong to the same project. When data sources do not belong to a project, Immuta uses a unique salt per data source for hashing to prevent masked values from being joined. (See the Why use masked joins? guide for an explanation of that behavior.) However, once you add Snowflake data sources to a project and enable masked joins, Immuta uses a consistent salt across all the data sources in that project to allow the join.

For more information about masked joins and enabling them for your project, see the Masked joins section of documentation.

The following guides offer practical guidance for handling common challenges and configurations.

Configure Ingress to complete your installation and access your Immuta application.

Configure TLS termination for an Ingress resource.

Verify artifacts hosted on the ocir.immuta.com OCI registry.

Follow these best practices when deploying Immuta in your production environment.

Update the credentials referenced in the Immuta Enterprise Helm chart.

Configure an external key-value cache (such as Redis or Memcached) with the Immuta Enterprise Helm chart.

Enable this legacy service for your deployment if you are using any of the legacy data platforms.

Configure pulling images from a private registry.

Tips when installing Immuta without internet access.

This guide demonstrates how to configure an external key-value cache (such as Redis or Memcached) with the Immuta Enterprise Helm chart (IEHC).

Prerequisite

The Production best practices guide must be completed before proceeding.

Redis

1. Edit secret immuta-secret that was created in the Immuta in production guide.

   Copy

   kubectl edit secret/immuta-secret

2. Add key-value IMMUTA_SERVER_CACHE_PROVIDER_OPTIONS_PASSWORD=<cache-password>.

Edit Helm values

Edit the immuta-values.yaml file to include the relevant Helm values listed below. Update all with your own values.

Perform a to apply the changes made to immuta-values.yaml.

This page describes the Azure Synapse Analytics integration, through which Immuta applies policies directly in Azure Synapse Analytics. For a tutorial on configuring Azure Synapse Analytics see the Azure Synapse Integration page.

Overview

The Azure Synapse Analytics is a policy push integration that allows Immuta to apply policies directly in Azure Synapse Analytics Dedicated SQL pools without the need for 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.

Architecture

This integration works on a per-Dedicated-SQL-pool basis: all of Immuta's policy definitions and user entitlements data need to be in the same pool as the target data sources because Dedicated SQL pools do not support cross-database joins. Immuta creates schemas inside the configured Dedicated SQL pool that contain policy-enforced views that users query.

When the integration is configured, the Application Admin specifies the

• Immuta database: This is the pre-existing database Immuta uses. Immuta will create views from the tables contained in this database, and all schemas and views created by Immuta will exist in this database, such as the schemas immuta_system, immuta_functions, and the immuta_procedures that contain the tables, views, UDFs, and stored procedures that support the integration.

• Immuta schema: The schema that Immuta manages. All views generated by Immuta for tables registered as data sources will be created in this schema.

• User profile delimiters: Since Azure Synapse Analytics dedicated SQL pools do not support array or hash objects, certain user access information is stored as delimited strings; the Application Admin can modify those delimiters to ensure they do not conflict with possible characters in strings.

For a tutorial on configuring the integration see the .

Synapse data sources are represented as views and are under one schema instead of a database, so their view names are a combination of their schema and table name, separated by an underscore.

For example, with a configuration that uses IMMUTA as the schema in the database dedicated_pool, the view name for the data source dedicated_pool.tpc.case would be dedicated_pool.IMMUTA.tpc_case.

You can see the view information on the data source details page under Connection Information.

This integration uses webhooks to keep views up-to-date with the corresponding Immuta data sources. When a data source or policy is created, updated, or disabled, a webhook is called that creates, modifies, or deletes the dynamic view in the Immuta schema. Note that only standard views are available because Azure Synapse Analytics Dedicated SQL pools do not support secure views.

The status of the integration is visible on the integrations tab of the Immuta application settings page. If errors occur in the integration, a banner will appear in the Immuta UI with guidance for remediating the error.

The definitions for each status and the state of configured data platform integrations is available in the . However, the UI consolidates these error statuses and provides detail in the error messages.

1. An Immuta Application Administrator , registering their initial Synapse Dedicated SQL pool with Immuta.

2. Immuta creates Immuta schemas inside the configured Synapse Dedicated SQL pool.

3. A Data Owner in Immuta as data sources. A Data Owner, Data Governor, or Administrator or in Immuta.

4. Data source metadata, tags, user metadata, and policy definitions are stored in Immuta's Metadata Database.

The how-to guides linked on this page illustrate how to integrate Databricks Spark with Immuta.

Requirements

• If Databricks Unity Catalog is enabled in a Databricks workspace, you must use an Immuta cluster policy when you set up the Databricks Spark integration to create an Immuta-enabled cluster.

• If Databricks Unity Catalog is not enabled in your Databricks workspace, you must disable Unity Catalog in your Immuta tenant before proceeding with your configuration of Databricks Spark:

  1. Navigate to the App Settings page and click Integration Settings.

  2. Uncheck the Enable Unity Catalog checkbox.

  3. Click Save.

This page outlines how to enable access to DBFS in Databricks for non-sensitive data. Databricks administrators should place the desired configuration in the Spark environment variables.

DBFS FUSE mount

This Databricks feature mounts DBFS to the local cluster filesystem at /dbfs. Although disabled when using process isolation, this feature can safely be enabled if raw, unfiltered data is not stored in DBFS and all users on the cluster are authorized to see each other’s files. When enabled, the entirety of DBFS essentially becomes a scratch path where users can read and write files in /dfbs/path/to/my/file as though they were local files.

For example,

%sh echo "I'm creating a new file in DBFS" > /dbfs/my/newfile.txt

In Python,

%python
with open("/dbfs/my/newfile.txt", "w") as f:
  f.write("I'm creating a new file in DBFS")

Note: This solution also works in R and Scala.

Enable DBFS FUSE mount

To enable the DBFS FUSE mount, set this configuration in the Spark environment variables: IMMUTA_SPARK_DATABRICKS_DBFS_MOUNT_ENABLED=true.

Scratch paths will work when performing arbitrary remote filesystem operations with fs magic or Scala dbutils.fs functions. For example,

To support %fs magic and Scala DBUtils with scratch paths, configure

To use dbutils in Python, set this configuration: immuta.spark.databricks.py4j.strict.enabled=false.

This section illustrates the workflow for getting a file from a remote scratch path, editing it locally with Python, and writing it back to a remote scratch path.

1. Get the file from remote storage:

2. Make a copy if you want to explicitly edit localScratchFile, as it will be read-only and owned by root:

3. Write the new file back to remote storage:

When using Delta Lake, the API does not go through the normal Spark execution path. This means that Immuta's Spark extensions do not provide protection for the API. To solve this issue and ensure that Immuta has control over what a user can access, the Delta Lake API is blocked.

Spark SQL can be used instead to give the same functionality with all of Immuta's data protections.

Requests

Below is a table of the Delta Lake API with the Spark SQL that may be used instead.

See here for a complete list of the .

When a table is created in a project workspace, you can merge a different Immuta data source from that workspace into that table you created.

1. .

2. Create a temporary view of the Immuta data source you want to merge into that table.

3. Use that temporary view as the data source you add to the project workspace.

4. Run the following command:

The how-to guides linked on this page illustrate how to integrate Databricks Unity Catalog with Immuta. See the reference guide for information about the Databricks Unity Catalog integration.

Requirements:

• Unity Catalog metastore created and attached to a Databricks workspace. Immuta supports configuring a single metastore for each configured integration, and that metastore may be attached to multiple Databricks workspaces.

• Unity Catalog enabled on your Databricks cluster or SQL warehouse. All SQL warehouses have Unity Catalog enabled if your workspace is attached to a Unity Catalog metastore.

The how-to guides linked on this page illustrate how to integrate Redshift with Immuta. See the reference guide for information about the Redshift integration.

Requirement: Redshift cluster with an RA3 node is required for the multi-database integration. For other instance types, you may configure a single-database integration using one of the Redshift Spectrum options.

Authentication

Registering the connection

The Snowflake integration supports the following authentication methods to register a connection. The credentials provided must be for an account with the permissions listed in the Register a Snowflake connection guide.

• Key pair

• Snowflake External OAuth

Snowflake External OAuth

Immuta's OAuth authentication method uses the Client Credentials Flow to integrate with Snowflake External OAuth. When a user configures the Snowflake integration, Immuta uses the token credentials (obtained using a certificate or passing a client secret) to craft an authenticated access token to connect with Snowflake. This allows organizations that already use Snowflake External OAuth to use that secure authentication with Immuta.

This is what will happen if you use Snowflake External OAuth to authenticate your Snowflake connection:

1. An Immuta application administrator registers the Snowflake connection.

2. Immuta creates a custom token and sends it to the authorization server.

3. The authorization server confirms the information sent from Immuta and issues an access token to Immuta.

4. Immuta sends the access token it received from the authorization server to Snowflake.

The built-in Immuta IAM can be used as a complete solution for authentication and user entitlement. However, you can connect your existing identity management provider to Immuta to use that system for authentication and user entitlement instead.

Each of the supported identity providers includes a specific set of configuration options that enable Immuta to communicate with the IAM system and map the users, permissions, groups, and attributes into Immuta.

See the for a list of supported providers and details.

See the for details about user provisioning and mapping user accounts to Immuta.

Immuta provides auditing features and governance reports so that data owners and governors can monitor users' access to data and detect anomalies in behavior.

You can view the information in these audit logs on .

See the for details about these capabilities and how they work with the Snowflake integration.

Immuta captures queries in Snowflake, making audit records more useful in assessing what users are doing. To audit Snowflake queries, Immuta runs a query in Snowflake to retrieve user query histories. Those histories are then populated into comprehensive audit logs. Immuta will only audit queries from Immuta users on objects registered as Immuta data sources.

Query audit can be . Audit ingestion will run at the schedule set on the . Audit ingestion can be manually requested at any time from the Immuta audit page. When manually requested, it will only search for new queries that were created since the last query that had been audited. The job is run in the background, so the new queries will not be immediately available.

See the for details about the contents of the logs and an example of the resulting audit record.

Immuta governance reports allow users with the GOVERNANCE Immuta permission to use a natural language builder to instantly create reports that delineate user activity across Immuta. These reports can be based on various entity types, including users, groups, projects, data sources, purposes, policy types, or connection types.

See the page for a list of report types and guidance.

The guides in this section illustrate how to install and deploy Immuta in your Kubernetes environment.

Prerequisites

Checklist

• RBAC permissions have been granted to create resources in the cluster.

Quickstart

Get started quickly with these essential guides. For a more comprehensive understanding and advanced configurations, explore the full suite of guides.

1. Complete the guide that corresponds with your Kubernetes cluster's distribution.

   • : This guide includes instructions for

     • Amazon Elastic Kubernetes Service (EKS)

     • Google Kubernetes Engine (GKE)

     • Microsoft Azure Kubernetes Service (AKS)

2. Complete the guide.

3. Complete the guide.

Immuta integrates with your data platforms so you can register your data and effectively manage access controls on that data.

This section includes guidance for connecting your data platform and keeping it synced with Immuta.

This reference guide outlines the features, policies, and audit capabilities of each data platform Immuta supports.

Integrations

The guides in these sections include information about how to connect your data platform to Immuta:

• Amazon Redshift

• Amazon S3

This reference guide outlines the actions and features that trigger Immuta queries in your remote platform that may incur cost.

Immuta integrates with your data platforms so you can register your data and effectively manage access controls on that data. This section includes concept, reference, and how-to guides for registering and managing data sources.

Run object sync

1. Navigate to the connection or connection-backed object.

2. Click Run Object Sync.

Edit the connection details

1. Click the Edit button in the Connection details box.

2. Edit the field you want:

   1. Host

   2. Port

   3. Warehouse

   4. Role: If you edit the role, ensure the new role has the

3. Select Validate, and once the validation is successful, select Save.

1. Click the Edit button in the Policy settings box.

2. Opt to enable or disable Impersonation.

   1. Enter the Impersonation Role.

3. Select Validate, and once the validation is successful, select

1. Click the Edit button in the Audit settings box.

2. Opt to enable or disable Query Audit: If you enable audit, ensure the system account has the .

3. Select Validate, and once the validation is successful, select Save.

1. Click the Edit button in the Object settings box.

2. Opt to enable or disable Policy Synchronization: When policy sync is enabled, all child objects will be represented by Immuta data sources and policies will be applied to the data sources.

3. Opt to Add Users and Groups as data owners:

Immuta is compatible with Snowflake Secure Data Sharing. Using both Immuta and Snowflake, organizations can share the policy-protected data of their Snowflake database with other Snowflake accounts with Immuta policies enforced in real time. This integration gives data consumers a live connection to the data and relieves data providers of the legal and technical burden of creating static data copies that leave their Snowflake environment.

Requirements:

• Snowflake Enterprise Edition or higher

Configuration

This method requires that the data consumer account is registered as an Immuta user with the Snowflake user name equal to the consuming account.

At that point, the user that represents the account being shared with can have the appropriate attributes and groups assigned to them, relevant to the data policies that need to be enforced. Once that user has access to the share in the consuming account (not managed by Immuta), they can query the share with the data policies from the producer account enforced because Immuta is treating that account as if they are a single user in Immuta.

For a tutorial on this workflow, see the .

Using Immuta with Snowflake Data Sharing allows the sharer to

• Only need limited knowledge of the context or goals of the existing policies in place: Because the sharer is not editing or creating policies to share their data, they only need a limited knowledge of how the policies work. Their main responsibility is making sure they properly represent the attributes of the data consumer (the account being shared to).

• Leave policies untouched.

Run object sync

1. Navigate to the connection or connection-backed object.

2. Click Run Object Sync.

Edit the connection details

1. Click the Edit button in the Connection details box.

2. Edit the field you want:

   1. Hostname

   2. Port

   3. SSL Mode

   4. Certificate Validation
3. Select Validate, and once the validation is successful, select Save.

1. Click the Edit button in the Object Sync settings box.

2. Opt to enable or disable object sync.

3. Opt to update the Start Time and Run Frequency from the dropdown menus.

4. Opt for all data objects to be scanned despite the policy sync setting using the checkbox.

1. Click the Edit button in the Object settings box.

2. Opt to enable or disable Policy Synchronization: When policy sync is enabled, all child objects will be represented by Immuta data sources and policies will be applied to the data sources.

3. Opt to Add Users and Groups as data owners:

Immuta is compatible with Snowflake Secure Data Sharing. Using both Immuta and Snowflake, organizations can share the policy-protected data of their Snowflake database with other Snowflake accounts with Immuta policies enforced in real time.

Prerequisite

• Snowflake connection registered

Create Immuta Policies to Protect the Data

Required Permission: Immuta: GOVERNANCE

Build Immuta data policies to fit your organization's compliance requirements.

It's important to understand that subscription policies are not relevant to Snowflake data shares, because the act of sharing the data is the subscription policy. Data policies can be enforced on the consuming account from the producer account on a share following these instructions.

Required Permission: Immuta: USER_ADMIN

To register the Snowflake data consumer in Immuta,

1. .

2. to match the account ID for the data consumer. This value is the output on the data consumer side when SELECT CURRENT_ACCOUNT() is run in Snowflake.

3. for your organization's policies.

4. .

Required Permission: Snowflake ACCOUNTADMIN

To share the policy-protected data source,

1. of the Snowflake table that has been registered in Immuta.

2. Grant reference usage on the Immuta database to the share you created:

   Replace the content in angle brackets above with the name of your Immuta database and Snowflake data share.

If a Databricks cluster needs to be manually updated to reflect changes in the Immuta init script or cluster policies, you can remove and set up your integration again to get the updated policies and init script.

1. Log in to Immuta as an Application Admin.

2. Click the App Settings icon in the navigation menu and scroll to the Integration Settings section.

3. Your existing Databricks Spark integration should be listed here; expand it and note the configuration values. Now select Remove to remove your integration.

4. Click Add Integration and select Databricks Integration to add a new integration.

5. Enter your Databricks Spark integration settings again as configured previously.

6. Click Add Integration to add the integration, and then select Configure Cluster Policies to set up the updated cluster policies and init script.

7. Select the cluster policies you wish to use for your Immuta-enabled Databricks clusters.

8. Automatically push cluster policies and the init script (recommended) or manually update your cluster policies.

   • Automatically push cluster policies

     1. Select Automatically Push Cluster Policies and enter your privileged Databricks access token. This token must have privileges to write to cluster policies.

9. Restart any Databricks clusters using these updated policies for the changes to take effect.

This guide demonstrates how to point the Immuta Enterprise Helm chart (IEHC) at a private container registry.

Registry with preserved repository paths

If the images keep their original repository paths (for example, stable/immuta-service stays stable/immuta-service), the only value required is the registry itself:

global:
  imageRegistry: <private-registry-fqdn>

Registry with a path prefix

If your registry imposes a path prefix (common with Artifactory or Harbor project layouts), map each repository with global.imageRepositoryMap. Do not override each component's image.repository individually:

global:
  imageRegistry: <private-registry-fqdn>
  imageRepositoryMap:
    stable/immuta-service: <prefix>/stable/immuta-service
    stable/audit-service: <prefix>/stable/audit-service
    # ...one entry per repository

List every repository the chart references:

helm show values oci://ocir.immuta.com/stable/immuta-enterprise --version 2026.2.0 | grep 'repository:' | sort -u

Pull secret

If your private registry requires authentication, create a pull secret and reference it globally:

kubectl create secret docker-registry immuta-private-registry \
    --docker-server=<private-registry-fqdn> \
    --docker-username=<username> \
    --docker-password=<password>

global:
  imagePullSecrets:
    - name: immuta-private-registry

This guide demonstrates how to update credentials referenced in the Immuta Enterprise Helm chart (IEHC).

1. Validate that secret immuta-secret exists in the current namespace.

2. Edit secret immuta-secret in place.

When installing Immuta, these are the supported options for getting audit logs from events in Immuta:

This page describes the Azure Synapse integration, configuration options, and features. See the for a tutorial on enabling the integration and these features through the app settings page.

The Databricks Unity Catalog integration supports the following authentication methods to register a connection. The credentials provided must be for an account with the permissions listed in the .

• Personal access token (PAT)

• OAuth machine-to-machine (M2M)

The built-in Immuta IAM can be used as a complete solution for authentication and user entitlement. However, you can connect your existing identity management provider to Immuta to use that system for authentication and user entitlement instead.

Each of the supported identity providers includes a specific set of configuration options that enable Immuta to communicate with the IAM system and map the users, permissions, groups, and attributes into Immuta.

Snowflake table grants simplifies the management of privileges in Snowflake when using Immuta. Instead of having to manually grant users access to tables registered in Immuta, you allow Immuta to manage privileges on your Snowflake tables and views according to subscription policies. Then, users subscribed to a data source in Immuta can view and query the Snowflake table, while users who are not subscribed to the data source cannot view or query the Snowflake table.

Enabling Snowflake table grants gives the following privileges to the Immuta Snowflake role:

• MANAGE GRANTS ON ACCOUNT allows the Immuta Snowflake role to grant and revoke SELECT privileges on Snowflake tables and views that have been added as data sources in Immuta.

The warehouse you select when configuring the Snowflake integration uses compute resources to set up the integration, register data sources, orchestrate policies, and run jobs like identification. Snowflake credit charges are based on the size of and amount of time the warehouse is active, not the number of queries run.

This document prescribes how and when to adjust the size and scale of clusters for your warehouse to manage workloads so that you can use Snowflake compute resources the most cost effectively.

In general, increase the size of and number of clusters for the warehouse to handle heavy workloads and multiple queries. Workloads are typically lighter after data sources are onboarded and policies are established in Immuta, so compute resources can be reduced after those workloads complete.

The Snowflake integration uses warehouse compute resources to sync policies created in Immuta to the Snowflake objects registered as data sources and, if enabled, to run and . Follow the guidelines below to adjust the warehouse size and scale according to your needs.

• Increase the of and of clusters for the warehouse during large policy syncs, updates, and changes.

To allow Immuta to automatically import table and column tags from Snowflake, enable Snowflake tag ingestion in the external catalog section of the Immuta app settings page.

Requirements

• A configured Snowflake connection

• The Snowflake user configuring the Snowflake tag ingestion must have the following privileges and should be able to access all securables registered as data sources:

When you register the Trino connection, Immuta generates an API key for you to add to your Immuta access control properties file for API authentication between Starburst (Trino) and Immuta. You can rotate this shared secret to mitigate potential security risks and comply with your organizational policies.

Required Immuta permission: APPLICATION_ADMIN

1. .

2. Navigate to the Trino connection in Immuta.

This guide demonstrates how to configure TLS termination for an Ingress resource.

Prerequisite

The Ingress configuration must be completed before proceeding.

1. Edit immuta-values.yaml to include the following Helm values.

   Copy

   gateway:
     ingress:
       hostname: <immuta-fqdn>
       annotations:
         nginx.ingress.kubernetes.io/auth-tls-secret: <namespace>/<secret-name>

2. Create a TLS secret from a given public/private PEM formatted key pair.

   Copy

   kubectl create secret tls <secret-name> --cert=path/to/tls.cert --key=path/to/tls.key

3. Perform a to apply the changes made to immuta-values.yaml.

Refer to the for further assistance.

1. Edit immuta-values.yaml to include the following Helm values.

2. Perform a to apply the changes made to immuta-values.yaml.

Refer to the for further assistance.

1. Edit immuta-values.yaml to include the following Helm values.

2. Perform a to apply the changes made to immuta-values.yaml.

Refer to the for further assistance.

1. Edit immuta-values.yaml to include the following Helm values.

2. Perform a to apply the changes made to immuta-values.yaml.

Refer to the for further assistance.

1. Edit immuta-values.yaml to include the following Helm values.

2. from a given public/private PEM formatted key pair.

3. Perform a to apply the changes made to immuta-values.yaml.

Refer to the for further assistance.

The query engine is no longer installed by default. This guide demonstrates how to enable the query engine using the Immuta Enterprise Helm chart (IEHC).

If you are using any of the legacy data platforms, you must enable the query engine.

Prerequisites

• The Immuta in production guide must be completed before proceeding.

• Validate that secret immuta-secret exists in the current namespace.

  Copy

  kubectl get secret/immuta-secret

Create Kubernetes secret

1. Create a file named secret-data.env with the following content.

2. Create secret named immuta-legacy-secret from file secret-data.env

3. Delete file secret-data.env, as it's no longer needed.

1. Edit the immuta-values.yaml file to include the following Helm values.

2. Update all in the immuta-values.yaml file.

Perform a to apply the changes made to immuta-values.yaml.

This guide demonstrates how to move the Immuta Enterprise Helm chart and its container images into an environment with no internet access. Two artifacts cross the boundary:

• The Helm chart archive (.tgz)

• The container images, copied by digest into archive files

The same process applies to the initial install and to every upgrade: Each release is one chart archive plus one set of images.

Every image is copied by digest, taken from the DIGESTS.md file inside the chart itself. A digest is content-addressed, so an image that arrives in your registry with the expected digest is bit-for-bit the image Immuta published; the transfer method cannot silently alter it.

• and on both the connected machine and a machine inside the air-gapped environment (skopeo moves the images; Helm pulls the chart on one side and installs it on the other).

• On the connected machine, skopeo and Helm are authenticated with ocir.immuta.com. Credentials are provided by Immuta; there is currently no self-service lookup. Contact your Immuta representative or if you do not have them.

• On the air-gapped machine, skopeo is authenticated with your private registry.

1. Download the Helm chart.

2. Extract DIGESTS.md (the chart's own manifest of every image it references, with digests) and convert it into a plain image list.

   Each line of images.txt is <image>:<tag> <digest>. This file travels with the archives and drives every later step.

3. (Optional) Verify Immuta's signature on each image before archiving, following the

Move the immuta-2026.2.0 directory into the air-gapped environment using your organization's approved transfer process. Everything needed is in that one directory: the chart archive, images.txt, and one .tar per image.

1. Push every image to your private registry, preserving each image's repository path and digest. Replace <private-registry-fqdn> with your registry.

   If your registry requires a path prefix (for example, an Artifactory repository), push to <private-registry-fqdn>/<prefix>/${path} instead, verify the same location in the next step, and map the repositories as described in the .

2. Verify the pushed images. Every digest in your registry must equal the digest in images.txt. Any mismatch fails loudly.

1. Point the chart at your registry. Because the repository paths were preserved, pointing the chart at your registry is a single value — no per-image overrides:

   If your registry requires authentication, also create a pull secret and set global.imagePullSecrets, as described in the . The credentials skopeo used to push are not used by Kubernetes to pull.

   If your registry requires a path prefix (for example, an Artifactory repository), map the repositories instead of overriding each image. See the for details.

2. Install or upgrade from the local chart archive. Wherever other guides reference oci://ocir.immuta.com/stable/immuta-enterprise, substitute the archive path and omit --version

This page provides a tutorial for enabling the Azure Synapse Analytics integration on the Immuta app settings page. To configure this integration via the Immuta API, see the Integrations API getting started guide.

For an overview of the integration, see the Azure Synapse Analytics overview documentation.

Requirement

A running Dedicated SQL pool is required.

Prerequisites

If you are using the OAuth authentication method,

• Ensure that Microsoft Entra ID is on the same account as the Azure Synapse Analytics workspace and dedicated SQL pool.

• Set up OAuth via Microsoft Entra ID app registration with a client secret.

• Select Accounts in this organizational directory only as the account type.

1. Click the App Settings icon in the navigation menu.

2. Click the Integrations tab.

3. Click the +Add Integration button and select Azure Synapse Analytics from the dropdown menu.

4. Complete the Host,

You have two options for configuring your Azure Synapse Analytic environment:

• : Grant Immuta one-time use of credentials to automatically configure your environment and the integration.

• : Run the Immuta script in your Azure Synapse Analytics environment yourself to configure the integration.

Enter the username and password in the Privileged User Credentials section.

1. Select Manual.

2. Download, fill out the appropriate fields, and run the bootstrap master script and bootstrap script linked in the Setup section. Note: The master script is not required if you're using the OAuth authentication method.

3. Select the authentication method:

Click Save.

.

1. Click the App Settings icon in the navigation menu.

2. Navigate to the Integrations tab and click the down arrow next to the Azure Synapse Analytics Integration.

3. Edit the field you want to change. Note any field shadowed is not editable, and the integration must be disabled and re-installed to change it.

4. Use the authentication method and credentials you provided when initially configuring the integration.

1. Click the App Settings icon in the navigation menu.

2. Navigate to the Integrations tab and click the down arrow next to the Azure Synapse Analytics Integration.

3. Click the checkbox to disable the integration.

4. Enter the credentials that were used to initially configure the integration.

Immuta offers two integrations for Databricks:

• Databricks Unity Catalog integration: This integration supports working with database objects registered in Unity Catalog.

• Databricks Spark integration: This integration supports working with database objects registered in the legacy Hive metastore.

Which integration should you use?

To determine which integration you should use, evaluate the following elements:

• Cluster runtime

  • Databricks Runtime 11.3 and newer: See the list below to determine which integration is supported for your data's location.

• Location of data: Where is your data?

  • Legacy Hive metastore: Databricks recommends that you migrate all data from the legacy Hive metastore to Unity Catalog. However, when this migration is not possible, use the to protect securables registered in the Hive metastore.

  • Unity Catalog: To protect securables registered in the Unity Catalog metastore, use the .

Databricks metastore magic allows you to migrate your data from the Databricks legacy Hive metastore to the Unity Catalog metastore while protecting data and maintaining your current processes in a single Immuta instance.

Databricks metastore magic is for organizations who intend to use the , but must still protect tables in the Hive metastore until they can migrate all of their data to Unity Catalog.

Unity Catalog support is enabled in Immuta.

Databricks has two built-in metastores that contain metadata about your tables, views, and storage credentials:

• Legacy Hive metastore: Created at the workspace level. This metastore contains metadata of the registered securables in that workspace available to query.

• Unity Catalog metastore: Created at the account level and is attached to one or more Databricks workspaces. This metastore contains metadata of the registered securables available to query. All clusters on that workspace use the configured metastore and all workspaces that are configured to use a single metastore share those securables.

Databricks allows you to use the legacy Hive metastore and the Unity Catalog metastore simultaneously. However, Unity Catalog does not support controls on the Hive metastore, so you must attach a Unity Catalog metastore to your workspace and move existing databases and tables to the attached Unity Catalog metastore to use the governance capabilities of Unity Catalog.

Immuta's Databricks Spark integration and Unity Catalog integration enforce access controls on the Hive and Unity Catalog metastores, respectively. However, because these metastores have two distinct security models, users were discouraged from using both in a single Immuta instance before metastore magic; the Databricks Spark integration and Unity Catalog integration were unaware of each other, so using both concurrently caused undefined behavior.

Metastore magic reconciles the distinct security models of the legacy Hive metastore and the Unity Catalog metastore, allowing you to use multiple metastores (specifically, the Hive metastore or alongside Unity Catalog metastores) within a Databricks workspace and single Immuta instance and keep policies enforced on all your tables as you migrate them. The diagram below shows Immuta enforcing policies on registered tables across workspaces.

In clusters A and D, Immuta enforces policies on data sources in each workspace's Hive metastore and in the Unity Catalog metastore shared by those workspaces. In clusters B, C, and E (which don't have Unity Catalog enabled in Databricks), Immuta enforces policies on data sources in the Hive metastores for each workspace.

With metastore magic, the Databricks Spark integration enforces policies only on data in the Hive metastore, while the Unity Catalog integration enforces policies on tables in the Unity Catalog metastore.

To enforce plugin-based policies on Hive metastore tables and Unity Catalog native controls on Unity Catalog metastore tables, enable the and the Databricks Unity Catalog integration. Note that some Immuta policies are not supported in the Databricks Unity Catalog integration. See the for details.

Databricks SQL cannot run the Databricks Spark plugin to protect tables, so Hive metastore data sources will not be policy enforced in Databricks SQL.

To enforce policies on data sources in Databricks SQL, use to manually lock down Hive metastore data sources and the Databricks Unity Catalog integration to protect tables in the Unity Catalog metastore. Table access control is enabled by default on SQL warehouses, and any Databricks cluster without the Immuta plugin must have table access control enabled.

When the Databricks Spark plugin is running on a Databricks cluster, all Databricks users running jobs or queries are either a privileged user or a non-privileged user:

• Privileged users: Privileged users can effectively read from and write to any table or view in the cluster Metastore, or any file path accessible by the cluster, without restriction. Privileged users are either Databricks workspace admins or users specified in IMMUTA_SPARK_ACL_ALLOWLIST. Any user writing queries or jobs impersonating another user is a non-privileged user, even if they are impersonating a privileged user.

  Privileged users have effective authority to read from and write to any securable in the cluster metastore or file path, because in almost all cases Databricks clusters running with the Immuta Spark plug-in installed have disabled Hive metastore table access control. However, if Hive metastore table access control is enabled on the cluster, privileged users will have the authority granted to them that is specified by table access control.

• Non-privileged users: Non-privileged users are any users who are not privileged users, and all authorization for non-privileged users is determined by Immuta policies.

Whether a user is a privileged user or a non-privileged user, for a given query or job, is cached once first determined, based on . This caching can be disabled entirely by setting the value of that environment variable to 0.

Usernames in Databricks must match the usernames in the connected Immuta tenant. By default, the Immuta Spark plugin checks the Databricks username against the username within Immuta's internal IAM to determine access. However, you can integrate your existing IAM with Immuta and use that instead of the default internal IAM. Ideally, you should use the same identity manager for Immuta that you use for Databricks. See the for a list of supported identity providers and protocols.

It is possible within Immuta to have multiple users share the same username if they exist within different IAMs. In this case, the cluster can be configured to look up users from a specified IAM. To do this, the value of the must be updated to be the targeted IAM ID configured within the Immuta tenant. The targeted IAM ID can be found on the . Each Databricks cluster can only be mapped to one IAM.

Databricks user impersonation allows a Databricks user to impersonate an Immuta user. With this feature,

• the Immuta user who is being impersonated does not have to have a Databricks account, but they must have an Immuta account.

• the Databricks user who is impersonating an Immuta user does not have to be associated with Immuta. For example, this could be a service account.

When acting under impersonation, the Databricks user loses their privileged access, so they can only access the tables the Immuta user has access to and only perform DDL commands when that user is acting under an allowed circumstance (such as workspaces, scratch paths, or non-Immuta reads/writes).

Use the to enable user impersonation.

Audited queries include an impersonationUser field, which identifies the Databricks user impersonating the Immuta user:

Once a Databricks securable is registered in Immuta as a data source and you are subscribed to that data source, you must access that data through SQL:

df = spark.sql("select * from immuta.table")

import org.apache.spark.sql.SparkSession

%sql
select * from immuta

library(SparkR)
df <- SparkR

See the sections below for more guidance on accessing data using Delta Lake, direct file reads in Spark for file paths, and user impersonation.

Delta Lake

When using Delta Lake, the API does not go through the normal Spark execution path. This means that Immuta's Spark extensions do not provide protection for the API. To solve this issue and ensure that Immuta has control over what a user can access, the Delta Lake API is blocked.

Spark SQL can be used instead to give the same functionality with all of Immuta's data protections. See the for a list of corresponding Spark SQL calls to use.

In addition to supporting direct file reads through workspace and scratch paths, Immuta allows direct file reads in Spark for file paths. As a result, users who prefer to interact with their data using file paths or who have existing workflows revolving around file paths can continue to use these workflows without rewriting those queries for Immuta.

When reading from a path in Spark, the Immuta Databricks Spark plugin queries the Immuta Web Service to find Databricks data sources for the current user that are backed by data from the specified path. If found, the query plan maps to the Immuta data source and follows existing code paths for policy enforcement.

Users can read data from individual parquet files in a sub-directory and partitioned data from a sub-directory (or by using a where predicate). Expand the blocks below to view examples of reading data using these methods.

• Direct file reads for Immuta data sources only apply to data sources created from tables, not data sources created from views or queries.

• If more than one data source has been created for a path, Immuta will use the first valid data source it finds. It is therefore not recommended to use this integration when more than one data source has been created for a path.

• In Databricks, multiple input paths are supported as long as they belong to the same data source.

• CSV-backed tables are not currently supported.

User impersonation allows Databricks users to query data as another Immuta user. To impersonate another user, see the .

If you're using AWS OpenSearch in your Immuta installation, use this how-to to set up the proper access and permissions needed for AWS role authentication.

• An OpenSearch domain

• The user setting up the permissions must have the following permissions:

  • Administrative access to your AWS account

This guide illustrates how to run R and Scala spark-submit jobs on Databricks, including prerequisites and caveats.

Before you can run spark-submit jobs on Databricks, complete the following steps.

1. Initialize the Spark session:

   1. Enter these settings into the R submit script to allow the R script to access Immuta data sources, scratch paths, and workspace tables:

Immuta offers several features to provide security for your users and Databricks clusters and to prove compliance and monitor for anomalies.

Immuta supports the following authentication methods to configure the Databricks Spark integration and register data sources:

• OAuth machine-to-machine (M2M): Immuta uses the to integrate with , which allows Immuta to authenticate with Databricks using a client secret. Once Databricks verifies the Immuta service principal’s identity using the client secret, Immuta is granted a temporary OAuth token to perform token-based authentication in subsequent requests. When that token expires (after one hour), Immuta requests a new temporary token. See the for more details.

Allow Immuta to create secure views of your external tables through one of these methods:

• that contains the external tables: Instead of creating an immuta database that manages all schemas and views created when Redshift data is registered in Immuta, the integration adds the Immuta-managed schemas and views to an existing database in Redshift

• and re-create all of your external tables in that database.

For an overview of the integration, see the documentation.

This page provides an overview of the Redshift integration in Immuta. For a tutorial detailing how to enable this integration, see the .

Redshift is a policy push integration that allows Immuta to apply policies directly in Redshift. This allows data analysts to query Redshift views directly instead of going through a proxy and have per-user policies dynamically applied at query time.

The Redshift integration will create views from the tables within the database specified when configured. Then, the user can choose the name for the schema where all the Immuta generated views will reside. Immuta will also create the schemas immuta_system, immuta_functions, and immuta_procedures to contain the tables, views, UDFs, and stored procedures that support the integration. Immuta then creates a system role and gives that system account the following privileges:

Once data is registered through the Snowflake connection, you will access your data through your Snowflake queries as you normally would. If you are subscribed to the data source, Immuta grants you access to the data in Snowflake.

When you submit a query, the Snowflake client submits the SQL query to the Snowflake server, which then processes the query and determines what data your role is allowed to see. Then, the Snowflake server queries the database and returns the query results to the Snowflake client, which then returns policy-enforced data to you.

The diagram below illustrates how Immuta, the Snowflake server, and Snowflake client interact to access data.

Because subscription policies are managed through roles, you must be acting under the role Immuta creates for you to get access to your subscribed data sources. When querying data in Snowflake, do one of the following:

• ​ that Immuta creates and manages. (For example, USE ROLE <prefix>_USER_<username>

This page describes the recommended workflow for setting up Immuta with Starburst (Trino). Following these steps connects your Starburst (Trino) environment, registers users, ingests metadata, and enables automated governance through global policies and access requests.

To complete this workflow, ensure you have:

• Access to a Starburst (Trino) account and the permissions required to configure the connection

• Access to install a plugin on your Trino cluster