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.
This page includes a list of the deprecated features with information about alternative options and dates when the feature will be removed.
Immuta CLI v1.4.0 was released July 10, 2024. It allows you to authenticate an export configuration to S3 using AWS IAM roles.
The following CLI audit
commands have been removed:
immuta audit exportConfig create:s3
; instead use immuta audit exportConfig create:s3:accessKey
immuta audit exportConfig update:s3
; instead use immuta audit exportConfig update:s3:accessKey
immuta audit exportConfig create:adls
; instead use immuta audit exportConfig create:adls:sasToken
immuta audit exportConfig update:adls
;instead use immuta audit exportConfig update:adls:sasToken
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.4.0/immuta_cli_SHA256SUMS.
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.
Immuta v2024.3.0 was released September 19, 2024.
Compliance with column length and precision in a Snowflake masking policy: Snowflake requires 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.
Data policies on Snowflake Iceberg tables: Users can now apply fine-grained access controls to Snowflake Iceberg tables, making support for Immuta data policies and subscription policies consistent across standard Snowflake table types.
Enhanced security: Regularly update your API credentials to mitigate potential security risks.
Compliance support: Meet security requirements that mandate periodic rotation of API keys.
Flexibility: Change the shared secret at any time after the initial integration setup.
Azure Purview data catalog tag ingestion: There is a standard (out-of-the-box) connector for tag ingestion from Azure Purview enterprise data catalog into Immuta. Previously, if tags resided in the Azure Purview data catalog, customers had to build the connector using Immuta's REST Catalog interface.
Adding a new external catalog integration automatically backfills tags for pre-existing data sources: Prior to this change, users had to manually link pre-existing data sources to the relevant external data catalog entry after a new external data catalog integration was set up, and only newly registered data sources were linked automatically. Now, Immuta triggers an auto-linking process for all unlinked data sources when a new external data catalog integration setup is saved. This change increases the level of automation, reduces cognitive and manual workload for data governors, and aligns external data catalog integration behavior with end user expectations.
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 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
Column masking with reversibility
Row minimization
Prior to this change, table statistics were collected for every newly onboarded object by default, unless 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 customers leverage custom fields because it allows them to explicitly control who can modify information associated with that field inside of Alation.
Alation standard tags are always modifiable by any user inside of Alation, which can pose a security risk if those were used to control access through Immuta policies.
Supporting both Alation tags and custom fields to be integrated into Immuta provides full flexibility to Immuta customers leveraging the Alation enterprise data catalog.
Schema monitoring for object type changes: Schema monitoring for Snowflake and Databricks Unity Catalog supports detecting and automatically reapplying policies on data sources that have changed their object type (for example, a VIEW that was changed into a TABLE or vice versa).
Previously, data owners were always asked to validate data source requests (which in turn removes the New
tag) related to data source and column changes, even if there was no actual policy present targeting the New
tag.
Now, data owners are only asked to validate data source requests if an actual policy is present that targets the New
tag. Otherwise the validation request for data owners gets skipped.
As a result, in the absence of a relevant policy, data owners will now have fewer data source requests to validate which saves them time and increases efficiency.
Schema monitoring enhancement for Databricks Unity Catalog: Schema monitoring for Databricks Unity Catalog now supports detecting and automatically reapplying policies on destructively recreated tables (from CREATE OR REPLACE statements), even if the table schema itself wasn’t changed.
Governance permission required for Discover: The Discover UI for managing automated data identification and classification is only accessible to users with the GOVERNANCE
permission in the Immuta application. Previously, Immuta users with permission to create data sources could also access the settings in the Discover UI.
Removed the overview tab on identification frameworks: Under Discover, each identification framework now has two tabs: identifiers and data sources. Prior to this change, there was an overview tab that linked to the other two tabs. When clicking into an identification framework, you now land directly on the identifiers tab.
Object accessed: The tables and columns that were queried
Tags: The Immuta table and column tags, including data catalog tags synchronized to Immuta, for queried tables and columns
Sensitivity classification: The columns' sensitivity in context of other queried columns if an Immuta classification framework is enabled at the time of audit event processing
Query duration: The amount of time it took to execute the query in seconds
Database name: The name of the Starburst (Trino) catalog
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.
Deprecated items remain in the product with minimal support until their end of life date.
Bug fix with breaking API change: 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.
New job orchestrator - Temporal: Immuta is migrating all background job processing to Temporal. Temporal is a durable execution engine that will allow Immuta to secure data at scale with fewer disruptions. Temporal requires a connection to PostgreSQL and will be deployed in 2024.3.0 by default.
New component - Detect Temporal Worker: The detect-temporal-worker
is the first Temporal worker that Immuta is introducing to the Immuta Enterprise Helm chart. This component is primarily used to support Immuta's audit record export feature.
New Feature Flag configuration: Feature flags are now managed under the global.featureFlags
Helm value instead of using environment variables.
Migration to ocir.immuta.com from registry.immuta.com: Container images for 2024.3.0 and beyond only exist in the ocir.immuta.com registry, and this is now the default registry for the Immuta Enterprise Helm chart. The legacy registry at registry.immuta.com will reach end of life when Immuta 2024.4.0 is released.
Fix for external tag ingestion related to Collibra Output Module API behavioral change: Incorrect filters were being passed to Collibra’s Output Module API when fetching column tag information. This resulted in a failed API request while linking or refreshing Collibra tags on a data source. Collibra’s Output Module API began performing additional request validation on approximately May 6, 2024, which indicated a problem. This fix ensures that the Collibra tag ingestion integration in Immuta is reflecting these changes. Without it, there was a residual risk that some incorrect column tags would get ingested.
Snowflake External OAuth: The form field Client Secret stopped being displayed in the UI for Snowflake data source registration, which led customers to believe that Snowflake External OAuth using client secret was no longer a supported authentication mechanism. This fix reintroduced the client secret field in the UI. Customers who had already registered data sources with Snowflake External OAuth previously via the UI, API, or CLI while the bug existed were not affected, since the issue only affected the UI but not the backend or programmatic interfaces.
You must be on Immuta version 2024.2 or newer to migrate directly to 2024.3.
You must migrate from registry.immuta.com to ocir.immuta.com to access the 2024.3 container images and Immuta Enterprise Helm chart.
The legacy registry at registry.immuta.com will reach end of life when Immuta 2024.4.0 is released.
You must migrate feature flags set using secure.extraEnvVars
to global.featureFlags
or you will see warning messages from Helm. (Deployment will not be impacted if not updated.)
AuditService
feature flag now defaults to true
; it no longer needs to be set.
detect
feature flag now defaults to true
; it no longer needs to be set.
auditLegacyViewHide
feature flag now defaults to true
; it no longer needs to be set.
6 new Kubernetes deployments have been added to the Immuta Enterprise Helm chart:
5 new pods for Temporal
1 new pod for the Detect Temporal Worker
The table below outlines the available features currently in preview for this release and when they were introduced.
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.
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.
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 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.
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
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.
: Domains are containers of data sources that allow you to assign data ownership and access management to specific business units, subject matter experts, or teams at the nexus of cross-functional groups. Domains support organizations building a data mesh architecture and implementing a federated governance approach to data security, which can accelerate local, domain-specific decision making processes and reduce risk for the business.
and integrations in general availability: This feature allows masked columns to be joined across data sources that belong to the same project, giving users additional capability for data analysis within a project while still securing sensitive data. Sensitive columns can be masked while still allowing users the ability to join on these within a project, helping organizations strike the correct balance between access and security.
: Databricks Unity Catalog integration now supports subscription policies (grants) on views. This enhancement allows customers to apply and manage access controls more effectively through subscription policies, streamlining data governance and access management. While subscription policies are now supported, data policies are not possible at this time due to the lack of support for row filters and column masks on views by Databricks.
: Users can rotate the shared secret used for API authentication between Starburst (Trino) and Immuta, which provides improved security management, compliance with organizational policies, and the following benefits:
Existing integrations will continue to function normally. Downtime is required when rotating the shared secret, so to ensure continuous operation of your integration, and establish a regular schedule for rotating your shared secret as part of your security best practices.
in preview: Customers who have tags defined and applied in Databricks Unity Catalog can seamlessly bring those tags into Immuta to leverage them for attribute based access control (ABAC), data classification, and data monitoring.
This feature is currently in preview at the design partner level. To use this feature in preview, you must have no more than 2,500 Unity Catalog data sources registered in Immuta. See the for expectations and details, and then reach out to your Immuta representative to enable this feature.
: In addition to Alation standard tags, Immuta’s Alation integration now also supports pulling information from Alation custom fields as tags into Immuta.
: Customizing sensitive data discovery is now easier and quicker with a single entry point for configuration. Instead of navigating to multiple pages in the Immuta application, use a single form to create an identifier for sensitive data and add tags and regex patterns.
: When schema monitoring is enabled, Immuta applies a New
tag whenever a new data source is added or its columns change. This allows governors to create policies that automatically apply to all new data sources and columns (such as masking new data by default).
: For customers who use domains to define data products, the Audit Activity
domain permission allows data product owners to review query activities of the data sources they manage using rich visualizations and dashboards. Without Immuta, customers would have to implement their own permission model if they wanted to allow specific users to only see query events related to certain selected tables (principle of least privilege). Immuta’s domain-scoped audit permission is an enabler to help open up access to query information to more users across the enterprise while staying compliant.
: Audit export supports AWS IAM authentication. Customers can use AWS assumed role-based authentication or access key authentication to secure access to S3 to export audit events.
: A new version of the CLI was released that includes new support for AWS IAM role authentication for audit export to S3 and some CLI breaking changes. See the CLI release note for more details.
: For customers who are using EMR 7.1 with Trino 435.1 and have audit requirements, the Immuta Trino 435.1 plugin now supports audit in the universal audit model. The Immuta Trino 435.1 plugin audit information is on par with the Immuta Trino 443 plugin. The Immuta Trino 435.1 plugin is supported on SaaS and 2024.2 and newer.
: Immuta query audit events for Starburst (Trino) will include the following information.
Feature | Deprecation notice | End of life (EOL) |
---|
Feature | Deprecation notice | End of life (EOL) |
---|
Feature | Availability | Introduced |
---|
Version | General availability date | End of support date | End of extended support date |
---|
Image | Digest |
---|
Databricks clusters (See the for supported Databricks runtimes.)
For details about the IAM protocols and providers in this section, see the support matrix in the .
Preview level | Access | Support | Documentation | Contact |
---|
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) |
---|
| 2024.3 | 2024.4 |
External policy handler | 2024.3 | 2024.4 |
Policy exemptions | 2024.3 | 2024.4 |
Quick create tab | 2024.3 | 2024.4 |
Unmask requests | 2024.3 | 2024.4 |
Conditional tags | 2024.3 | 2024.4 |
2024.3 | September 2024 | December 2024 | February 2025 |
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 |
registry.immuta.com/immuta/immuta-service:2024.2.0 |
|
registry.immuta.com/immuta/immuta-db:2024.2.0 |
|
registry.immuta.com/immuta/immuta-fingerprint:2024.2.0 |
|
registry.immuta.com/immuta/audit-service:2024.2.0 |
|
registry.immuta.com/immuta/audit-export-cronjob:2024.2.0 |
|
registry.immuta.com/immuta/classify-service:2024.2.0 |
|
registry.immuta.com/immuta/cache:2024.2.0 |
|
2023.3 | 2024.4 |
Public preview | September 2023 (v2023.3) |
Private preview | January 2024 (v2024.1) |
Design partner | 2024.3 |
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 |
Private preview | September 2024 (v2024.3) |
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 |
Private preview | December 2022 (v2022.5) |
Private preview | September 2023 (v2024.1) |
Private preview | February 2024 (v2024.2) |
Private preview | April 2024 (v2024.2) |
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 |
CREATE_FILTER permission | None | 2024.3 | 2024.4 |
External policy handler | None | 2024.3 | 2024.4 |
Policy exemptions | 2024.3 | 2024.4 |
Quick create tab | None | 2024.3 | 2024.4 |
Unmask requests | None | 2024.3 | 2024.4 |
Derived data sources | None | 2024.2 | 2024.4 |
Managing the default subscription policy | 2024.2 | 2024.4 |
Legacy audit self-managed container output | 2024.1 | 2024.4 |
Legacy | 2023.3 | 2024.4 |
Legacy sensitive data discovery | 2023.3 | 2024.4 |
Legacy audit UI | 2023.3 | 2024.3 |
Legacy audit query text | 2024.2 | 2024.3 |
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 |
Query text has been removed from all legacy audit records. Instead, use , which by default contain query text.
Allow in the Snowflake and Databricks Unity Catalog integrations
Specify exempted users directly in your policies using the principles of
Create an "Allow individually selected users"
See the for external container options
Export UAM events to or
, which still contain query text