Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section includes release notes, features in preview, a support matrix, and the long term support model description.
This page includes a list of new features, enhancements, bug fixes, and migration notes.
This page includes a description of Immuta's release lifecycle model.
This page includes illustrations of changes in the product over the last 12 months and since the last LTS release.
This page includes an overview of the data platforms, identity managers, external catalogs, and web browsers that Immuta supports.
This page includes a list of new features, enhancements, and bug fixes for the Immuta CLI.
This page includes a list of image digests to verify the integrity of Immuta images that you pull.
This section includes an overview of Immuta's feature preview program and a list of features currently in preview.
New end of support date for 2024.1
The end of support date for 2024.1 has been updated to July 31, 2024.
Immuta v2024.2.6 was released September 11, 2024.
Resolved an issue that prevented users from being able to subscribe to Redshift data sources.
The following attributes will now be excluded from the GET /user
response if the requesting user does not have the USER_ADMIN
Immuta permission:
bimAuthorizations
iamAuthorizations
authorizations
Immuta v2024.2.5 was released September 6, 2024.
Updated encryption of information related to REST catalog passwords in the system bundle.
Existing Snowflake and Redshift integrations did not migrate properly after an upgrade.
Users encountered a JSON parsing error when querying Redshift data sources if policies were applied that contained backslashes in user attributes.
Fixed an issue that caused Google BigQuery data sources to get stuck in an unhealthy state.
Masking policies failed to apply to complex data type columns in Databricks if property names within the struct included special characters.
Vulnerabilities addressed:
CVE-2024-37890
CVE-2024-39338
CWE-29
Only users with the CREATE_DATA_SOURCE
permission are authorized to use the POST api/v2/data
endpoint; users without that permission will be blocked and get a 403 status returned.
Immuta v2024.2.4 was released August 9, 2024.
Databricks Unity Catalog ARRAY, MAP, and STRUCT type columns support masking with NULL.
In some instances, data and subscription policies remained in a pending state and were not applied to data in the remote platform.
Addressed issues that prevented Starburst (Trino) from working properly with the query engine disabled.
Fix to address the New
tag being incorrectly applied to data sources and locking down access to data.
Masking Snowflake OBJECT
type columns with NULL failed.
CVE-2024-6345
addressed
Immuta v2024.2.3 was released July 26, 2024.
Previously, data source tasks were created for all events discovered by schema monitoring. Now, the following events will only have data source tasks created if there is a policy targeting the auto-applied New
tag:
Column added
Column type changed
Data source created
Immuta would allow for the data dictionary to be updated to empty, but this empty state was not supported by backend functions.
External user IDs failed to save if the username contained a psql slash command ("\e", "\t", "\q", etc.).
Data sources in view-based integrations were sometimes locked down and inaccessible to users after being registered in Immuta, even if no policies applied to them.
Immuta v2024.2.2 was released June 25, 2024.
Comply with column length and precision in a Snowflake masking policy: Snowflake is soon requiring the outputs of masked columns to comply with the length, scale, and precision of what the Snowflake columns require. To comply with this Snowflake behavior change, Immuta truncates the output values in masked columns to match the Snowflake column requirements so that users' queries continue to complete successfully.
Vulnerabilities addressed:
CVE-2024-4068
CVE-2024-4067
Immuta v2024.2.1 was released June 7, 2024.
Trino universal audit model available with Trino 435 using the Immuta Trino plugin 435.1: For customers that are using EMR 7.1 with Trino 435.1, and have audit requirements, the Immuta Trino 435.1 plugin now supports audit in universal audit model. The Immuta Trino 435.1 plugin audit information is on par with Immuta Trino 443 plugin. The Immuta Trino 435.1 plugin is supported on SaaS and 2024.2 and later.
Data owners can now see audit events for the data sources that they own without having the AUDIT Immuta permission: Data owners can see query events for their data sources on the audit page, data overview page, data source pages, and the data source activity tab. They can also inspect Immuta audit events on the audit page and activity tab for the data sources they own. This enhancement gives data owners full visibility of activity in the data sources they own.
UI performance issues
Fixes to address issues that caused Immuta to fail passing the SSL cert supplied by customers using an external metadata database.
IAM integrations that had SCIM enabled did not support backslashes \
in usernames.
Subscription policies that included variables (@host
, @database
, @schema
, @table
) caused UI performance issues.
Immuta was not escaping or encoding special backslash characters (/
, \
) in usernames, which resulted in bad API requests.
Deleting and re-enabling a Redshift integration caused issues for data sources with custom schema/table names and formats.
Databricks Unity Catalog integration configuration failed to save if Oauth token passthrough was used as the authentication method.
Fixes to address an issue that caused Redshift data source subscriptions to fail if users were subscribed to a large number of them.
Immuta v2024.2.0 was released May 10, 2024.
Immuta Detect is a tool that monitors your data environment and provides analytic dashboards in the Immuta UI based on audit information of your data use.
Query monitoring with webhook notifications for Databricks, Snowflake and Starburst (Trino) in public preview: Immuta Detect monitors help you surface non-compliant data combinations and maintain data availability through data platform configuration changes. Monitors can notify you when user activity metrics exceed your intended operating thresholds. Monitors work with query tags, query execution outcomes, and Immuta Discover classification sensitivities when enabled.
Dynamic query classification in private preview: For a query that joins tables, Immuta uses the same classification rules applied to tables and applies those rules to columns of the query. Immuta applies a new set of classification tags to the query columns and calculates sensitivity for the query event in the audit record. These query classification tags are not included on the table's data dictionary.
Universal audit model: Over 90 audit events are captured and can be exported to S3 or ADLS Gen2. See the full list of supported events on the Universal audit model (UAM) page.
Native sensitive data discovery (SDD): Native SDD is available for Snowflake and Databricks in general availability, and Starburst (Trino) and Redshift in private preview. Native SDD automatically discovers and tags your data based on the identifiers it matches but, unlike non-native SDD, it does not persist or move any of your data. It is enabled by default.
SDD tag context: Native SDD leaves legacy SDD tags in place when they are not found upon a subsequent re-scan of a data source. Customers who begin using native SDD can see results with no impact to prior legacy SDD tags. See the Migrate legacy to native SDD page for more details.
Built-in classification frameworks in private preview: Immuta comes preconfigured with a bundle of classification frameworks for use out-of-the-box once endorsed by your organization's admins. These frameworks are designed by Immuta’s Legal Engineering and Research Engineering teams and informed by data privacy regulations and security standards: GDPR, CCPA, GLBA, HIPAA, PCI, and global best practices. They are a starting point for companies to customize to their own classification, security, and risk policies.
Write policies for Starburst (Trino) and Amazon S3 in private preview: In addition to read operations, Immuta's Starburst (Trino) and Amazon S3 integrations now support fine-grained access permissions for write operations.
Project-scoped purpose exceptions for Snowflake and Databricks Unity Catalog integrations in public preview: Row- and column-level policies can now account for purposes and projects for additional security. With this policy configuration, a user will only be able to view the data the policy applied to if they are acting under a certain purpose and that data is within their current project. Purpose exception policies ensure data is only being used for the intended purposes.
Support protecting more than 10,000 objects with Unity Catalog row- and column- level policies: Users can now mask more than 10,000 columns or tables with row filters, removing the previous limitation in the Unity Catalog integration. This enhancement provides greater flexibility and scalability for data masking operations, allowing users to effectively secure sensitive data across larger datasets.
OAuth M2M support for Databricks Unity Catalog: Immuta supports establishing connections to Databricks using OAuth Machine-to-Machine (M2M) authentication. This feature enhances security and simplifies the process of integrating Databricks with Immuta, leveraging the robust capabilities of OAuth M2M authentication.
Faster query performance with Snowflake memoizable functions in public preview: When a policy is applied to a column, Immuta now uses Snowflake memoizable functions to cache the result of common lookups in the policy encapsulated in the called function. Subsequently, when users query a column with the applied policy, Immuta leverages the cached result, which significantly enhances query performance. Contact your customer success manager for more details.
Disable external usernames with invalid Databricks identities: Databricks user identities for Immuta users will now be automatically marked as invalid when the user is not found during policy application. This will prevent them from being affected by Databricks policy until manually marked as valid again in their Immuta user profile. This change drastically improves syncing performance of subscription policies for Databricks Unity Catalog integrations when Immuta users are not present in the Databricks environment.
Disable k-anonymization by default and allow users to opt-in: When a k-anonymization policy is applied to a data source, the columns targeted by the policy are queried under a fingerprinting process that generates rules that enforce the k-anonymity. The results of this query, which may contain data that is subject to regulatory constraints such as GDPR or HIPAA, are stored in Immuta's metadata database.
To ensure this process does not violate your organization's data localization regulations, you need to first activate this masking policy type before you can use it in your Immuta tenant. To enable k-anonymization, adjust the setting on the Immuta app settings page. If you have existing k-anonymization policies, those policies will not be affected by this change.
Collibra PII assignments: When pulling personally identifiable information (PII) from Collibra, Immuta now includes and differentiates true
and false
value assignments as Personally Identifiable Information.true
and Personally Identifiable Information.false
to more accurately reflect how PII is set in Collibra.
Integrations API: The Integrations API will be enabled by default when users upgrade to 2024.2. With this feature, the Integrations UI is in a new section of the product. Also, when creating native Snowflake integrations, tag extraction will no longer be an option. Users can set up tag extraction and manage existing Snowflake external catalogs via the External Catalog section of the Immuta app settings page.
Running table statistics only if required (instead of by default): Table statistics consist of row counts, identification of high cardinality columns, and a sample data fingerprint. Immuta needs to collect this information in order to support the following data access policy types:
Column masking with randomized response
Column masking with format preserving masking
Column masking with k-anonymization
Column masking with rounding
Row minimization
Prior to this change, table statistics would be collected for every newly onboarded object by default, except if the object had a Skip_Stats
tag applied. Post this change, table statistics are now only collected on a data object once they are required (i.e., if one of the above-mentioned policy types is applied). Even then, the Skip_Stats
tag continues to be respected. This change results in performance improvements, as the number of standard operations during data object onboarding is significantly reduced.
Alation custom fields integration: In addition to Alation standard tags, Immuta’s Alation integration now also supports pulling information from Alation custom fields as tags into Immuta.
Improved user experience for managing users, data sources, and policies in public preview: This deployment includes significant user experience updates focused on enhancing Immuta's key entities: users, data sources, and policies.
The People section has a more intuitive experience with notable changes. Users and groups have been split into two separate tabs. The first tab provides an overview of a user or group, while the second tab contains detailed settings, such as permissions, attributes, and associated groups.
Another enhancement in the People section is the new Attributes page, which centralizes all information about an attribute, including the users or groups it applies to.
The Data Sources section has been completely redesigned to offer a more efficient search and filter experience. Users can preview details of a data source through expandable rows on the list and access bulk actions for data sources more easily.
The Policy section includes an updated list with improved search and filter capabilities. Additionally, a policy detail page allows users to view comprehensive policy information, take action, edit policies, and see a list of targeted data sources.
“Pending” policy state: A new Pending
policy state indicates when background jobs are running to update permissions after a policy is created or changed. Once the Pending
state changes to Active
, all policy changes have been enforced on affected data sources.
Color coding for data source health: The health status for each data source on the data source list page now uses color coding to provide a visual for users so they can quickly determine whether they should take action related to the health of data sources. Additionally, unhealthy data sources are ranked at the top of the list on the data source page to ensure that when users log in to Immuta they are aware that unhealthy data sources exist in the system. Prior to this change, users had to click through all data source pages or had to explicitly set up a filter to achieve the same behavior.
Updates to button labels: Two buttons have been renamed to align their labels more closely with their functionality.
The "Sync Native Policies" button has been renamed to "Sync Data Policies" to better reflect its function.
The "Refresh Native Views/Policies" button has been renamed to "Refresh Native Views/Data Policies" for improved accuracy.
The new user profile page separates information better and makes it easier to understand.
Keyboard shortcuts are now available for some common functions. Keep an eye out for in-app guidance that helps with how to use them.
The account menu is wider for better readability and now has an option to toggle between light and dark mode. By default, Immuta still uses your browser settings.
Browser tabs tell you which page you’re on, instead of all being labeled “Immuta Console.” A new, adaptive favicon allows you to still tell that it’s Immuta at-a-glance, whether you’re in light or dark mode.
Fix to address a UI issue that led customers to believe that disabled users were not getting their access revoked. The UI has been updated and disabled users are now being filtered out from the data source members tab.
Deprecated items remain in the product with minimal support until their end of life date.
Change to POST /tag/{modelType}/{modelId}
endpoint: The POST /tag/{modelType}/{modelId}
endpoint (which adds tags to models that can be tagged, such as data sources and projects) can only apply tags that exist to these models. This update presents one breaking change: A 404
status will now be returned with the tag(s) that were not valid instead of a 200
status, and no tags will be processed if any invalid tags are found.
Change to POST /tag/column/{datasource_id}_{column_name}
endpoint: The POST /tag/column/{datasource_id}_{column_name}
endpoint (which adds tags to columns on data sources) can only tag existing columns on data sources. It does this by checking the dictionary associated with the data source to see if the desired column exists on the data source. This deployment introduces two breaking changes:
Column does not exist 404
: When the column does not exist on the data source, a 404
status is now returned instead of a 200
.
Dictionary does not exist 404
: When an associated dictionary does not exist on the specified data source (that you have access to add tags to), a 404
status is now returned instead of a 403
.
Change to POST /project
: Users will receive a 422
status error instead of a 400
status error when trying to create a new project name that would result in a database conflict on the project's unique name.
Change to POST /api/v2/data
response: creating
will not be returned in the response when using this endpoint the first time; the response will just include bulkId
and connectionString
. However, when updating a data source using POST /api/v2/data
, the response will include creating: []
(with no data source names inside the array).
You must be on Immuta version 2022.5 or newer to migrate directly to 2024.2.
Integrations API: If you did not have integrations API turned on prior to 2024.2.0, when the tenants are restarted after upgrading, the system will perform a short migration of the native integrations from the global configuration to the new native integrations bometadata tables in support of integrations API.
General availability date: The date the software version is available to all customers.
Support period: The period of time between the general availability date and the end of support date. During this period, Immuta will keep the version up-to-date with important bug fixes and security updates.
End of support date: The date when Immuta will stop backporting critical bug fixes to the release. For LTS releases, this is one year after the general availability date. For all other major releases, this is typically one month after the next release (four months after the general availability date).
Extended support period: The period of time between the end of support date and the extended support date. During this period, Immuta will no longer provide bug fix updates to the version, but will investigate and troubleshoot issues. Immuta recommends to upgrade before this period.
End of extended support date: The date when Immuta is no longer obligated to investigate issues raised against the release. The end of extended support date will occur three months after the next major release.
Immuta releases one long-term support (LTS) version each year that is kept up-to-date with important bug fixes and security updates for one year. Our customers who prefer to remain on an Immuta version for an extended period of time can install the LTS versions and be confident that their implementation is stable and supported.
Major releases that are not designated “LTS” will be updated with important bug fixes until one month after the next major release.
Why should I choose the LTS version?
Immuta recognizes that frequent upgrades are not feasible for many of our customers and wants to ensure that customers can remain on versions of the product that are well-supported. The LTS model ensures that customers who choose to stay on an Immuta version for a longer time will benefit from stability and security updates without being exposed to the risk of functionality changes.
I am on an older version today. Do I have to upgrade to an LTS version?
Immuta recommends that customers on older versions start planning an upgrade to the LTS or a more recent quarterly version.
Can I still use older versions?
The Customer Success team will continue to answer questions and help you troubleshoot older versions as much as possible. However, Immuta will not provide code updates to versions that have reached their end of support date.
What if I want the latest version of Immuta?
Great! Staying up-to-date with the latest Immuta release is the best way to get the latest features and improvements. The LTS model does not impact you. You will always be supported with critical bug fixes and security updates when you are using one of the two most recent major releases of Immuta. Immuta recommends to plan for quarterly upgrades to stay on a supported version when not on the LTS.
How are the non-LTS versions supported?
Major releases that are not designated LTS are supported with critical bug fixes through the next two major release dates, which is typically a four-month period, giving time for an upgrade each quarter.
What are considered critical bug fixes?
Cybersecurity vulnerabilities (CVEs) that are categorized as critical or high and have a possible impact within the Immuta solution.
Bugs that cause a severe and ongoing disruption to our customers' ability to conduct business in production, including critical performance impacts.
Feature | Deprecation notice | End of life (EOL) |
---|---|---|
Feature | Deprecation notice | End of life (EOL) |
---|---|---|
Version | General availability date | End of support date | End of extended support date |
---|---|---|---|
Derived data sources
2024.2
2024.4
Managing the default subscription policy
2024.2
2024.4
Legacy sensitive data discovery (SDD)
2023.3
2024.4
Amazon EMR Spark & Hive proxy connector
2023.2
2024.2
Azure Data Lake Storage proxy connector
2023.3
2024.2
Azure SQL Proxy Connector
2023.3
2024.2
Data source expiration dates
2023.2
2024.2
dbt integration
2024.1
2024.2
Databricks Spark with Unity Catalog support
2024.1
2024.2
Non-Unity Databricks SQL view-based integration
2023.3
2024.2
Discussions tab
2023.3
2024.2
HIPAA expert determination and templated policies (HIPAA and CCPA)
2023.3
2024.2
Interpolated WHERE clause
2023.2
2024.2
Legacy Amazon S3 proxy
2023.3
2024.2
Legacy Starburst (Trino) integration
2023.2
2024.2
MySQL proxy connector
2024.1
2024.2
Query editor (now turned off by default)
2023.3
Starting to remove with 2024.2
Single Node Docker installation
2023.2
2024.2
Legacy Snowflake view-based integration (Snowflake integration without Snowflake Governance features)
2023.2
2024.2
Tableau connector
2023.3
2024.2
2024.2 LTS
April 2024
April 2025
June 2025
2024.1
January 2024
May 2024
October 2024
2023.4
November 2023
May 2024
October 2024
2023.3
September 2023
December 2023
September 2024
2023.2
July 2023
December 2023
June 2024
2023.1
March 2023
September 2023
March 2024
2022.5 LTS
December 2022
April 2024
July 2024
Immuta supports the following databases.
Amazon Redshift
Amazon Redshift Serverless
Amazon Redshift Spectrum
Amazon S3
Azure Synapse Analytics (Immuta only supports Dedicated SQL pools, not Serverless SQL pools.)
Google BigQuery
Databricks Unity Catalog:
Databricks clusters (See the Databricks Installation guide for supported Databricks runtimes.)
Databricks SQL
Snowflake
Starburst (Trino)
The following legacy databases are currently supported for existing customers.
Apache Impala
Amazon Athena
CDH Spark
Elasticsearch
Greenplum
Netezza
Oracle
PostgreSQL
SQL Server
Immuta supports the following Kubernetes distributions. Click a link below for details.
Amazon Elastic Kubernetes Service (EKS)
Azure Kubernetes Service (AKS)
Google Kubernetes Engine (GKE)
OpenShift
Rancher Kubernetes Engine (RKE)
Immuta supports these external catalogs. Click a link below for configuration instructions.
For details about the IAM protocols and providers in this section, see the support matrix in the Identity Managers Overview.
Immuta fully supports these IAM protocols:
AD/LDAP
SAML 2.0
OpenID Connect 1.0
These are common providers that support the protocols listed above. However, this list may not be all-inclusive, and if a provider stops supporting one of those protocols, Immuta may not fully support that provider.
Active Directory
ADFS
Amazon Cognito
Centrify
JumpCloud
Keycloak
Microsoft Entra ID
Okta
OneLogin
OpenLDAP and other LDAP servers
Oracle Access Manager
Ping Identity
Immuta supports the following web browsers.
Firefox
Google Chrome
Microsoft Edge
Immuta CLI v1.3.0 was released April 4, 2024. It allows you to export universal audit model (UAM) events to ADLS Gen2.
Linux x86_64 (amd64):
Linux ARMv8 (arm64):
Darwin x86_64 (amd64):
Darwin ARMv8 (arm64):
Download and add the binary to a directory in your system's $PATH as immuta.exe
:
The SHA 256 checksum is available to verify the file at https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.3.0/immuta_cli_SHA256SUMS.
Immuta CLI v1.2.1 was released November 20, 2023. It fixes a bug with the integrations API.
Linux x86_64 (amd64):
Linux ARMv8 (arm64):
Darwin x86_64 (amd64):
Darwin ARMv8 (arm64):
Download and add the binary to a directory in your system's $PATH as immuta.exe
:
The SHA 256 checksum is available to verify the file at https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.1/immuta_cli_SHA256SUMS.
Immuta CLI v1.2.0 was released October 2, 2023. It fixes a bug with the audit export.
Linux x86_64 (amd64):
Linux ARMv8 (arm64):
Darwin x86_64 (amd64):
Darwin ARMv8 (arm64):
Download and add the binary to a directory in your system's $PATH as immuta.exe
:
The SHA 256 checksum is available to verify the file at https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0/immuta_cli_SHA256SUMS.
Immuta CLI v1.2.0-1 was released August 19, 2022. It allows you to export universal audit model (UAM) events to S3.
Linux x86_64 (amd64):
Linux ARMv8 (arm64):
Darwin x86_64 (amd64):
Darwin ARMv8 (arm64):
Download and add the binary to a directory in your system's $PATH as immuta.exe
:
The SHA 256 checksum is available to verify the file at https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0-1/immuta_cli_SHA256SUMS.
Immuta CLI v1.1.0 was released August 19, 2022. It allows you to overwrite existing files in output directory targets when you specify the --force
flag to clone your Immuta tenant or policies. If this --force
flag is omitted, you will receive an error when the output directory exists and is not empty.
Linux x86_64 (amd64):
Linux ARMv8 (arm64):
Darwin x86_64 (amd64):
Darwin ARMv8 (arm64):
Download and add the binary to a directory in your system's $PATH as immuta.exe
:
The SHA 256 checksum is available to verify the file at https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.1.0/immuta_cli_SHA256SUMS.
The Immuta CLI v1.0.0 was released April, 26, 2022. It includes new commands that allow users to manage sensitive data discovery.
Linux x86_64 (amd64):
Linux ARMv8 (arm64):
Darwin x86_64 (amd64):
Darwin ARMv8 (arm64):
Download and add the binary to a directory in your system's $PATH as immuta.exe
:
The SHA 256 checksum is available to verify the file at https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.0.0/immuta_cli_SHA256SUMS.
Run sensitive data discovery (SDD): The immuta sdd run
command allows you to run SDD using the CLI instead of the API or UI. You can specify data sources on which to run SDD, or you can run SDD on all data sources.
Manage patterns: The immuta sdd classifier
command and its sub commands allow you to create, search for, update, and delete sensitive data discovery rules.
Manage identification frameworks: The immuta sdd template
command and its sub commands allow you to create, search for, update, and delete sensitive data discovery frameworks. Global frameworks must be managed through the Immuta UI.
--output
or -o
flag allows you to specify yaml or json for the output.
--template
option for the immuta api
command has been changed to --outputTemplate
. Additionally, this option is now available for all commands so that users can customize the output.
version
is now a flag instead of a command.
Running immuta policy clone
when there were no policies available to clone did not indicate that a target directory was not created or updated. The CLI now prints the message No global policies available to clone
.
The verbose
option is deprecated (in favor of the --output
option).
The version
command is deprecated.
Use the image digests below to verify the integrity of Immuta images that you pull.
Image digests may be different than the digests shown below if you are using a registry proxy, such as JFrog Artifactory or Sonatype Nexus, to proxy requests to the Immuta container registry. Registry proxies modify the image manifest resulting in a new image digest.
Preview levels
The design partner level is for SaaS customers only.
In this preview level, Immuta launches an initial limited-functionality feature with a select group of customers to solve a specific challenge. The goal of this preview level is to validate that the solution solves the challenge in a way that is valuable, usable, and feasible.
Throughout the feature development and launch processes, Product Management and Engineering meet regularly with the customer to gather feedback and help implement the feature. When the process starts, entire portions of the feature may be missing from the product, but the customer receives regular (potentially weekly) updates of the feature from the Engineering team.
Design partner level features do not have support SLAs or Immuta customer support engagement; the customer solely works with the Immuta Product team. Design partner feature functionality is subject to change, discontinuation, and discontinuation of support at Immuta’s sole discretion. Immuta makes no delivery date commitments.
Private preview features approximately match the product offered to the general public. Immuta only makes changes to the feature after gathering feedback or discovering unexpected implications of the feature.
Immuta invites customers to the private preview, and they are required to engage with Immuta Product Management to provide feedback about the feature.
Immuta makes commercially reasonable efforts to support private preview functionality; however, such support is not subject to SLA targets or processes. Immuta immediately closes support tickets that are filed and redirects customers to the Product Manager in charge of the feature. Private preview functionality is subject to change, discontinuation, and discontinuation of support at Immuta’s sole discretion.
Public preview features match the product offered to the general public. Immuta only changes the feature to address bugs.
Public preview features are fully documented on the Immuta website, but customers are expected (not required) to engage with Product Management and Customer Success to enable the feature.
Immuta makes commercially reasonable efforts to support public preview functionality; however, such support is not subject to the normal SLA targets and will not be considered priority level 1 or 2. If public preview functionality impacts or is believed to reasonably impact other fully supported functionality, the customer must disable the public preview functionality; SLA targets and processes only apply once the public preview functionality is disabled. Issues discovered (even at priority levels 3 and 4) with public preview functionality will be resolved at Immuta’s sole discretion.
GA features are complete and available to all customers. Full SLA targets and processes apply.
The table below outlines the available features currently in preview for this release and when they were introduced.
Image | Digest |
---|---|
Preview level | Access | Support | Documentation | Contact |
---|
Feature | Availability | Introduced |
---|
Feature | Use this alternative feature instead | Deprecation notice | End of life (EOL) |
---|
Feature | Use this alternative feature instead | Deprecation notice | End of life (EOL) |
---|
Feature | Use this alternative feature instead | Deprecation notice | End of life (EOL) |
---|
registry.immuta.com/immuta/immuta-service:2024.2.0
sha256:47a7345fc28131f63249a53baf781688c5ea4a971957b97be77c0aad232b90dd
registry.immuta.com/immuta/immuta-service:2024.2.1
sha256:2ce3f4d7a5fda058a4d4b7367f15a755b157109f9ea5050733b0b478ea5a1e7c
registry.immuta.com/immuta/immuta-db:2024.2.0
sha256:4763b988207637ecb1e5affc106d75b581fb7d4d54e8b8e9824bf37705637f2c
registry.immuta.com/immuta/immuta-db:2024.2.1
sha256:c5328b6fe1c752f8e8a575dc9e3981f7fa2dee1718d46ab50960be564fb5ad3f
registry.immuta.com/immuta/immuta-fingerprint:2024.2.0
sha256:aa9d80963d2c3de0bf5d7c61183ab517ec2b0d383bdc0671df7e961d9ba33db7
registry.immuta.com/immuta/immuta-fingerprint:2024.2.1
sha256:f263b25fa754127d5149a16812322eba174fd8fe0de57df38054e3eab0a559bc
registry.immuta.com/immuta/audit-service:2024.2.0
sha256:a27248bef7aa70ddd278bf1eb430158f8a96da630bac1b6c28955e885c013775
registry.immuta.com/immuta/audit-service:2024.2.1
sha256:7dfce549d625ac563f2d75252481731144e23bf09bce435e13d0d45a8327e00b
registry.immuta.com/immuta/audit-export-cronjob:2024.2.0
sha256:9af5a3d2c00fca9966e5d40b0bf2c3a6a9920bbfd1773c05a90aa40c13062de6
registry.immuta.com/immuta/audit-export-cronjob:2024.2.1
sha256:2f867a52c56dc7c8531fc4b45ef0201db76cc9ee93b986c26dc73d08e13da6c2
registry.immuta.com/immuta/classify-service:2024.2.0
sha256:d40ebad2ab7f7991be92bdae6807abe277f98ad723537122142c0dbdefc7ee4f
registry.immuta.com/immuta/classify-service:2024.2.1
sha256:0f9879837eab87953fb56a9f5d8dc3bbceea9d67a2564d278b2342b784c1831d
registry.immuta.com/immuta/cache:2024.2.0
sha256:7be69d8c89d94726a96bcf595da8f8c53b8d8a99625db482ebf039a11ca74fe2
registry.immuta.com/immuta/cache:2024.2.1
sha256:40a4a660afc9c6348759c64e04afe68c077c7fb660b6b6a12a6ab5f92b9008f1
Invitation only | None | None | Product Management (required) |
Invitation only | Best effort | Yes | Product Management (required) |
Customer request | Limited SLAs | Yes | Customer Success and Sales Engineering |
No action required | Full SLAs | Yes | Customer Success and Sales Engineering |
Public preview | September 2023 (v2023.3) |
Private preview | January 2024 (v2024.1) |
Data source list updates | Public preview | January 2024 (v2024.2) |
Private preview | December 2023 |
Private preview | December 2023 |
Private preview | September 2022 (v2022.3) |
Public preview | July 2022 (v2022.2) |
Private preview | October 2022 (v2022.3) |
Public preview | 2021 |
Public preview | February 2024 |
Public preview | November 2021 (v2021.4) |
Private preview | April 2024 (v2024.2) |
Public preview | April 2024 (v2024.2) |
Private preview | October 2022 (v2022.4) |
Public preview | 2021 |
Public preview | April 2024 (v2024.2.0) |
Private preview | December 2022 (v2022.5) |
Private preview | September 2023 (v2024.1) |
Private preview | February 2024 (v2024.2) |
Private preview | April 2024 (v2024.2) |
Derived data sources | None | 2024.2 | 2024.4 |
Legacy sensitive data discovery | 2023.3 | 2024.4 |
Managing the default subscription policy | 2024.2 | 2024.4 |
Legacy audit UI | 2023.3 | 2024.3 |
Legacy audit query text | 2024.2 | 2024.3 |
Legacy | 2023.3 | 2024.4 |
Legacy audit self-managed container output | 2024.1 | 2024.4 |
Amazon EMR Spark & Hive proxy connector | None | 2023.2 | 2024.2 |
Azure Data Lake Storage proxy connector | None | 2023.2 | 2024.2 |
Azure SQL Proxy Connector | None | 2023.3 | 2024.2 |
Data source expiration dates | None | 2023.2 | 2024.2 |
dbt integration | None | 2024.1 | 2024.2 |
Databricks Spark with Unity Catalog support | 2024.1 | 2024.2 |
Non-Unity Databricks SQL view-based integration | 2023.3 | 2024.2 |
Discussions tab | None | 2023.3 | 2024.2 |
HIPAA expert determination and templated policies (HIPAA and CCPA) | 2023.3 | 2024.2 |
Interpolated WHERE clause | 2023.2 | 2024.2 |
Legacy Amazon S3 proxy | 2023.3 | 2024.2 |
Legacy Starburst (Trino) integration | 2023.2 | 2024.2 |
MySQL proxy connector | None | 2024.1 | 2024.2 |
Query editor (turned off by default on all new installations) | None | 2023.3 | 2024.2 |
Single Node Docker installation | 2023.2 | 2024.2 |
Legacy Snowflake view-based integration (Snowflake integration without Snowflake Governance features) | 2023.2 | 2024.2 |
Tableau connector | None | 2023.3 | 2024.2 |
Allow in the Snowflake and Databricks Unity Catalog integrations
Project-scoped purpose exceptions for and integrations
Create an "Allow individually selected users"
, which still contain query text
Export UAM events to or
See the for external container options