The table below outlines feature changes and deprecations from the previous LTS release to the current one.

12-month changelog

The table below outlines the feature changes and deprecations over the last 12 months.

Immuta v2024.1.13

Immuta v2024.1.13 was released June 25, 2024.

Enhancement

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.

Bug fix

Data sources were sometimes locked down and inaccessible to users after being registered in Immuta, even if no policies applied to them.

Immuta v2024.1.12

Immuta v2024.1.12 was released June 6, 2024.

Bug fix

Deleting and re-enabling a Redshift integration caused issues for data sources with custom schema/table names and formats.

Immuta v2024.1.11

Immuta v2024.1.11 was released May 31, 2024.

Bug fixes

• Users were unable to access Redshift data sources they had recently registered.

• Immuta was not escaping or encoding special backslash characters (/, \) in usernames, which resulted in bad API requests.

Immuta v2024.1.10

Immuta v2024.1.10 was released May 22, 2024.

Bug fixes

• IAM integrations that had SCIM enabled did not support backslashes \ in usernames.

• UI performance improvements when subscription policies contain special variables (@host, @database, @schema, @table).

Immuta v2024.1.9

Immuta v2024.1.9 was released May 13, 2024.

Bug fixes

• If a subscription policy was built against user attributes it caused UI errors and performance issues.

• Performance improvements of subscription policies.

Immuta v2024.1.8

Immuta v2024.1.8 was released May 7, 2024.

Bug fixes

• The Unity Catalog integration configuration could not be saved if OAuth token passthrough was used as the authentication method.

• External user IDs failed to save if the username contained a psql slash command (\e, , \q, etc.).

Immuta v2024.1.7

Immuta v2024.1.7 was released April 26, 2024.

Bug fix

Immuta failed to connect to users' external metadata database.

Immuta v2024.1.6

Immuta v2024.1.6 was released April 10, 2024.

Bug fixes

• Long subscription policies caused out of memory errors.

• Users could not create or update integration configurations if they used Snowflake External OAuth.

• Users encountered out of memory errors when navigating to the project equalization page if their Immuta tenant had over 200,000 data sources, 400 subscription policies, 200 users, and 4 million tags.

• Performance improvements of native project workspaces.

Feature release March 25, 2024

Write policies for Starburst (Trino) (available in Immuta v2024.1 and newer as of March 25, 2024): In addition to read operations, Immuta's Starburst (Trino) integration now supports fine-grained access permissions for write operations. In its default setting, write operations control the authorization of SQL operations that perform data modification. Administrators can include more operations (such as ALTER and DROP tables) to be authorized as write operations through advanced configuration. Contact your customer success representative to learn more.

Immuta v2024.1.5

Immuta v2024.1.5 was released March 8, 2024.

Bug fix

Users who had access to many data sources encountered a 500 error when trying to view data sources on the data source or project pages.

Immuta v2024.1.4

Immuta v2024.1.4 was released February 28, 2024.

Bug fixes

Vulnerabilities addressed:

• CVE-2023-5869

• CVE-2024-0985

Immuta v2024.1.3

Immuta v2024.1.3 was released February 22, 2024.

Enhancement

Faster query performance with Snowflake memoizable functions: 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, resulting in significant enhancements to query performance.

To enable support for memoizable functions, please contact your Immuta customer success representative.

Bug fix

Additional fixes to address the following issue: Any attempt to stage or remove automatic subscription policies resulted in revokes not going through to Databricks if there was a casing mismatch between the principal user from Databricks and the external username mapped to Immuta.

Immuta v2024.1.2

Immuta v2024.1.2 was released February 9, 2024.

Bug fix

Additional fixes to address an issue that prevented revokes from going through to Databricks if

• an automatic subscription policy was staged or deleted and

• there was a casing mismatch between the principal user from Databricks and the external username mapped to Immuta.

Immuta v2024.1.1

Immuta v2024.1.1 was released February 2, 2024.

Bug fixes

• Fix to address issues with performance of background jobs.

• Any attempt to stage or remove automatic subscription policies resulted in revokes not going through to Databricks if there was a casing mismatch between the principal user from Databricks and the external username mapped to Immuta.

Immuta v2024.1.0

Immuta v2024.1.0 was released January 25, 2024.

New features

• Amazon S3 integration: Immuta’s Amazon S3 integration enhances the management of permissions in complex data lakes on object storage. Eliminate scalability concerns as you enforce S3 access effortlessly. You can grant users time-bound access to files and folders, creating a security posture with zero-standing permissions, a gold-standard for compliance.

  Additionally, you can grant access to human identities seamlessly through Identity Providers (IdPs) like Okta, Microsoft Entra ID, and more, thanks to integration with AWS IAM Identity Center. With the implementation of attribute-based access controls (ABAC) for S3, Immuta provides a simplified and efficient approach to managing data lake permissions. The privileges you set using the Amazon S3 integration can apply anywhere, from the CLI, to your applications using AWS SDKs, and on Amazon EMR Spark and Amazon SageMaker. Elevate your data governance with these advanced capabilities and experience a seamless and secure data access environment. Contact your customer success manager for more details.

• Integrations API: The integrations API allows you to integrate your remote data platform with Immuta so that Immuta can manage and enforce access controls on your data.

• Write policies: Write policies is a new capability to manage user write access authorizations via policy (enabling users to modify data in data source objects). This release supports the new functionality for Snowflake and Databricks Unity catalog integrations. Contact your customer success manager for more details.

Deprecations and breaking changes

Deprecated items remain in the product with minimal support until their end of life date.

v2024.1 migration note

All users must be on Immuta version 2022.5 or newer to migrate directly to 2024.1.

Databases

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)

Legacy Databases

The following legacy databases are currently supported for existing customers.

• Apache Impala

• Amazon Athena

• Amazon EMR Hive - Deprecated in 2023.2

• Amazon EMR Spark - Deprecated in 2023.2

• Amazon S3 proxy - Deprecated in 2023.3

• Azure Data Lake Storage - Deprecated in 2023.3

• Azure SQL - Deprecated in 2023.3

• CDH Spark

• Elasticsearch

• Greenplum

• MySQL - Deprecated in 2024.1

• Netezza

• Oracle

• PostgreSQL

• SQL Server

Kubernetes Versions

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)

External Catalogs

Immuta supports these external catalogs. Click a link below for configuration instructions.

• Alation

• Collibra

• Custom REST Catalogs

• Snowflake

External IAMs

For details about the IAM protocols and providers in this section, see the support matrix in the Identity Managers Overview.

IAM Protocols

Immuta fully supports these IAM protocols:

• AD/LDAP

• SAML 2.0

• OpenID Connect 1.0

IAM Providers

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

• Google

• JumpCloud

• Keycloak

• Microsoft Entra ID

• Okta

• OneLogin

• OpenLDAP and other LDAP servers

• Oracle Access Manager

• Ping Identity

Web Browsers

Immuta supports the following web browsers.

• Firefox

• Google Chrome

• Microsoft Edge

Immuta CLI v1.3.0

Immuta CLI v1.3.0 was released April 4, 2024. It allows you to export universal audit model (UAM) events to ADLS Gen2.

Downloads

Linux

• Linux x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.3.0/immuta_cli_linux_amd64 && chmod +x immuta

• Linux ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.3.0/immuta_cli_linux_arm64 && chmod +x immuta

MacOS

• Darwin x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.3.0/immuta_cli_darwin_amd64 && chmod +x immuta

• Darwin ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.3.0/immuta_cli_darwin_arm64 && chmod +x immuta

Windows

Download and add the binary to a directory in your system's $PATH as immuta.exe:

• https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.3.0/immuta_cli_windows_amd64

Verify the File

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

Immuta CLI v1.2.1 was released November 20, 2023. It fixes a bug with the integrations API.

Downloads

Linux

• Linux x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.1/immuta_cli_linux_amd64 && chmod +x immuta

• Linux ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.1/immuta_cli_linux_arm64 && chmod +x immuta

MacOS

• Darwin x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.1/immuta_cli_darwin_amd64 && chmod +x immuta

• Darwin ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.1/immuta_cli_darwin_arm64 && chmod +x immuta

Windows

Download and add the binary to a directory in your system's $PATH as immuta.exe:

• https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.1/immuta_cli_windows_amd64

Verify the File

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

Immuta CLI v1.2.0 was released October 2, 2023. It fixes a bug with the audit export.

Downloads

Linux

• Linux x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0/immuta_cli_linux_amd64 && chmod +x immuta

• Linux ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0/immuta_cli_linux_arm64 && chmod +x immuta

MacOS

• Darwin x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0/immuta_cli_darwin_amd64 && chmod +x immuta

• Darwin ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0/immuta_cli_darwin_arm64 && chmod +x immuta

Windows

Download and add the binary to a directory in your system's $PATH as immuta.exe:

• https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0/immuta_cli_windows_amd64

Verify the File

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

Immuta CLI v1.2.0-1 was released August 19, 2022. It allows you to export universal audit model (UAM) events to S3.

Downloads

Linux

• Linux x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0-1/immuta_cli_linux_amd64 && chmod +x immuta

• Linux ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0-1/immuta_cli_linux_arm64 && chmod +x immuta

MacOS

• Darwin x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0-1/immuta_cli_darwin_amd64 && chmod +x immuta

• Darwin ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0-1/immuta_cli_darwin_arm64 && chmod +x immuta

Windows

Download and add the binary to a directory in your system's $PATH as immuta.exe:

• https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.2.0-1/immuta_cli_windows_amd64

Verify the File

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

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.

Downloads

Linux

• Linux x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.1.0/immuta_cli_linux_amd64 && chmod +x immuta

• Linux ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.1.0/immuta_cli_linux_arm64 && chmod +x immuta

MacOS

• Darwin x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.1.0/immuta_cli_darwin_amd64 && chmod +x immuta

• Darwin ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.1.0/immuta_cli_darwin_arm64 && chmod +x immuta

Windows

Download and add the binary to a directory in your system's $PATH as immuta.exe:

• https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.1.0/immuta_cli_windows_amd64

Verify the File

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.

Immuta CLI v1.0.0

The Immuta CLI v1.0.0 was released April, 26, 2022. It includes new commands that allow users to manage sensitive data discovery.

Downloads

Linux

• Linux x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.0.0/immuta_cli_linux_amd64 && chmod +x immuta

• Linux ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.0.0/immuta_cli_linux_arm64 && chmod +x immuta

MacOS

• Darwin x86_64 (amd64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.0.0/immuta_cli_darwin_amd64 && chmod +x immuta

• Darwin ARMv8 (arm64):

  Copy

  curl -Lo immuta https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.0.0/immuta_cli_darwin_arm64 && chmod +x immuta

Windows

Download and add the binary to a directory in your system's $PATH as immuta.exe:

• https://immuta-platform-artifacts.s3.amazonaws.com/cli/v1.0.0/immuta_cli_windows_amd64

Verify the File

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.

New Commands

• 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.

Updates and Enhancements

• --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.

Fixes

• 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.

Deprecations

• The verbose option is deprecated (in favor of the --output option).

• The version command is deprecated.

4.13.5

Changes:

• Update to immuta-deploy-tools v2.4.6

  • Optimized memory usage when restoring database backups

  • Optimized disk usage when creating database backups

• Added extraEnv and extraVolumeMounts to web service init containers

• Added support for custom annotations for ConfigMaps and Secrets

4.13.4

Changes:

• Web Service port is now configurable

• Update to immuta-deploy-tools v2.4.4

  • Only allow privileged users to drop and create database during restore

  • Only connect to Postgres database during restore when running as a superuser

Fix:

• Fixed bug where Google Cloud credentials were not properly mounted during restore process

4.13.3

Changes:

• Added support for <component>.image.digest to allow image digests to be used instead of image tags.

• Added endpointslices to built-in Ingress Controller Role.

Fix:

• No longer deploy database-initialize resources when restore is disabled.

• Google Cloud Secret Key is no longer referenced when restore is disabled.

4.13.2

Changes:

• Update to immuta-deploy-tools v2.4.3

4.13.1

Fix:

• Fix malformed YAML error during generation of database-initialize hook manifest when backup.restore.enabled is true

4.13.0

Fix:

• Update to immuta-deploy-tools v2.4.2

  • Adds support for Azure managed identities.

  • Support non-superuser restore from backup taken by a superuser.

Changes:

• Support for Query Engine rehydration.

  • Use queryEngine.rehydration.enabled

• Deprecate openSSLConfig in favor of openSSLConfigMapName.

  • Where openSSLConfigMapName is an existing Configmap that's managed outside of Helm, but located in the same namespace.

• Do not manage external database backup/restore process when a superuser is not set.

• Deprecate externalDatabase.backup.enabled and externalDatabase.restore.enabled

  • Use backup.enabled and backup.restore.enabled.

4.12.1

Fix:

• Update immuta-deploy-tools to v2.3.1

  • Vulnerability fixes

4.12.0

Fix:

• Update to immuta-deploy-tools v2.3.0

  • Fixed bug where backup files would be cleaned up based on Last Modified Date instead of the timestamp in the filename.

  • Vulnerability fixes

Changes:

• All replica counts default to 1

• Database Migrations execute as init-container for internal and external metadata

• Enabled Patroni Failsafe mode by default

• Persistence is enabled by default

• Deprecate HA Redis Cache feature

• Deprecate hooks.databaseMigration and hooks.databaseInitialize.initVars

• Deprecate ingressClass

  • Use web.ingress.ingressClassName or web.ingress.annotation instead

4.11.1

Immuta Helm 4.11.1 includes bug fixes and stability improvements.

Fix:

• Update to immuta-deploy-tools v2.2.0.

• Fixed bug where database migrations failed to execute on databases not named bometadata.

• Only set automountServiceAccountToken on Pods when rbac.create is enabled.

4.11.0

Immuta Helm 4.11.0 includes bug-fixes for database backups.

Changes

Update:

• Update immuta-deploy-tools image to v2.1.9.

4.10.0

Immuta Helm Chart 4.10.0 contains bug fixes and stability improvements.

Fix:

• Update immuta-deploy-tools to v2.1.8.

• Default to Immuta 2022.4.1.

• Backups failed when tls.enabled was set to false.

• extraEnv processing returned null if valueFrom was used instead of value.

• Use tls-secret.type of kubernetes.io/tls when nginxIngress.enabled is set to false.

• Base Web Ingress annotations couldn't be removed or overridden.

• Couldn't disable external TLS while leaving internal TLS enabled.

• Couldn't restore from a specific backup file in Helm Chart.

• Immuta Helm backup failed when storageClass did not support ReadWriteMany.

• Couldn't enable database restores by default on new Helm deployments.

• Fix regression when using max-backup-count for database backups.

Update:

• Kubernetes 1.24 support.

• Increase default Patroni log level to INFO instead of WARNING.

4.9.7

Immuta Helm 4.9.7 includes bug-fixes for external metadata database migrations.

Changes

Update:

• Update immuta-deploy-tools image to v2.1.7.

• Default to Immuta 2022.3.1.

4.9.6

Immuta Helm 4.9.6 includes bug-fixes for external metadata database migrations.

Changes

Update:

• Update immuta-deploy-tools image to v2.1.6.

• Support Immuta 2022.3.0.

4.9.5

Immuta Helm 4.9.5 includes bug-fixes for external metadata db and backups.

Changes

Update:

• Update immuta-deploy-tools image to v2.1.5.

• Default to Immuta 2022.1.1.

Fix:

• Fix TLS behavior when external is disabled.

• Fix restore when specifying backup file.

• Fix backup.maxBackupCount behavior. A previous version introduced a regression that ignored the value.

4.9.3

Immuta Helm 4.9.3 includes bug-fixes and small database initialization configuration updates.

Update:

• Support passing database initialization variables to immuta-deploy-tools.

Fix:

• Fix backup.restore.allowMissingArchive value reference typo.

• Fix validation logic for external database passwords when existingSecret is specified.

4.9.2

Helm 4.9.2 adds functionality to improve security context granularity.

Update:

• Default to Immuta 2022.1.0.

• Remove service token auto mounting.

• Deprecate <component>.securityContext in favor of <component>.podSecurityContext.

• Granular security context support.

4.9.0

Immuta Helm 4.9.0 includes bug-fixes and updates to various components.

Changes

Update:

• Update immuta-deploy-tools image to v2.1.4

Fix:

• Do not create or mount volume to /var/lib/immuta for older versions of Immuta (<2022.1.0)

4.8.1

Immuta Helm 4.8.1 includes bug-fixes and enables some use-cases that were previously blocked.

Changes

Update:

• Add volume to support uploading Immuta plugins for restricted OpenShift security contexts.

• Add support for custom Azure blob domain for backups.

Fix:

• Use credentials from existing secret when creating backups.

• Remove validation requirement for external database passwords when an existing secret is provided.

• Set Patroni config environment variable for interactive shell sessions.

• Don't create an ODBC volume (/var/lib/immuta/odbc) for older versions of Immuta (< 2021.4.0).

4.8.0

This release includes changes to support deploying Immuta on OpenShift and updates the built-in Ingress-Nginx controller to support Kubernetes 1.22+.

Support for OpenShift

It is now possible to deploy the Immuta Helm Chart on OpenShift Kubernetes clusters. For more details see Deploy Immuta on OpenShift.

Nginx Ingress Controller v1

The Ingress-Nginx controller has been updated from v0.x to v1.x in order to support Kubernetes 1.22+. Due to breaking changes, the v1 release of Ingress-Nginx does not support Kubernetes versions older than 1.19. Users who have existing deployments on older Kubernetes clusters can set nginxIngress.controller.image.tag=v0.49.3 in the Immuta Helm values.

Changes

Update:

• Upgrade Ingress-Nginx controller to v1.1.0.

• Creation of Ingress resources can now be disabled.

• Support configuring Patroni to use ConfigMaps for leader election (required for deployment on OpenShift).

• Added pod anti-affinity rules for Redis cache Pods.

• Allow annotations to be set on the Query Engine client Service.

• Add Helm value cache.updateStrategy to allow update strategy to be set for cache workloads.

Fix:

• Fix for database restores from blob storage into an external database.

• Fix for backup SecurityContext overrides not taking effect.

4.7.0

This release includes new features and other changes intended to improve the usability of the Immuta Helm Chart.

New features include the ability to use an external PostgreSQL database for Immuta metadata and the option to use Redis as a cache. Other notable improvements are the ability to set a global image registry override, support for the PodSecurityPolicy RunAsUser rule MustRunAsNonRoot, configurable SecurityContext runAsUser settings for most components, and support for Kubernetes API resources that have moved out of beta.

External PostgreSQL Database Support

It is now possible to use an external PostgreSQL instance as the Immuta Metadata Database when running Immuta in Kubernetes. When enabled, this functionality replaces the built-in PostgreSQL metadata database that runs in Kubernetes. This functionality is enabled by setting database.enabled=false and passing the connection information for the PostgreSQL instance under the key externalDatabase.

database:
  enabled: false
externalDatabase:
  hostname: external-postgres.database.hostname
  password: bometauserpassword
  superuser:
    username: postgres
    password: postgrespassword

For existing deployments it is possible to migrate from the built-in database to an external database. In order to migrate, backups must be configured, and a backup should be taken immediately prior to migrating. The process of migrating can be done by running helm upgrade with the external database Helm values and backup.restore.enabled=true.

This functionality is compatible with Immuta 2021.3+.

Redis Cache

There is now the option to use Redis as the cache implementation for Immuta. The primary motivation for offering this option is to enable the use of TLS for network traffic between the Immuta web service and cache pods.

In order to select Redis as the cache implementation for Immuta, set the Helm value cache.type=redis when installing the Immuta Helm Chart.

cache:
  type: redis

TLS is enabled for internal network traffic by default when Redis is used, so unless tls.enabledInternal=false is set, TLS will be used for network traffic between Immuta and Redis.

When Redis is selected as the cache for Immuta, the Immuta Web Service pods will contain an additional container that runs envoy as an ambassador sidecar; the envoy container is named "cache-proxy-sidecar." In this configuration, kubectl logs commands must include the flag --container=service in order to access logs for the Immuta Web Service.

Global Image Registry Override

It is now possible to configure the container image registry globally for all images referenced by the Immuta Helm Chart.

global:
  imageRegistry: registry.mycorp.com

The default value for global.imageRegistry is registry.immuta.com.

Immuta images are referenced relative to the configured image registry by adding the repository prefix immuta/, for example registry.mycorp.com/immuta/immuta-service.

Third-party images are referenced without the immuta/ prefix. The images that this applies to are

• ingress-ngnix-controller

• memcached

• redis

• envoyproxy-envoy-alpine

If these images are not available in the custom registry under the root prefix, it is possible to configure the image repository. This may be the case if you have pulled these images and pushed them to your registry under the immuta/ prefix.

cache:
  redis:
    image:
      repository: immuta/redis
  memcached:
    image:
      repository: immuta/memcached
  proxySidecar:
    image:
      repository: immuta/envoyproxy-envoy-alpine
nginxIngress:
  controller:
    image:
      repository: immuta/ingress-nginx-controller

Support for MustRunAsNonRoot Policies

Init containers for initializing database and Query Engine persistent volumes no longer run as root. In addition to increasing overall security by running init containers as an unprivileged user, this also means that Immuta is now compatible with the PodSecurityPolicy RunAsUser rule MustRunAsNonRoot or other similar policies.

Configurable SecurityContext runAsUser for Most Components

The Pod SecurityContext is now configurable for all components except for Nginx Ingress. This means that the user ID that the Pods run as can now be customized by setting securityContext.runAsUser for the components that support it. The following table shows which components are configurable for various Immuta versions.

backup:
  securityContext:
    runAsUser: 31234
cache:
  securityContext:
    runAsUser: 31234
database:
  securityContext:
    runAsUser: 31234
fingerprint:
  securityContext:
    runAsUser: 31234
queryEngine:
  securityContext:
    runAsUser: 31234
web:
  securityContext:
    runAsUser: 31234

Kubernetes API Version Updates

The resources created by the Immuta Helm Chart will now use stable versions of the following resources when they are available on the Kubernetes cluster.

• networking.k8s.io/v1 for Ingress resources.

• batch/v1 for CronJob resources.

• policy/v1 for PodDisruptionBudget resources.

Migration Notes

Upgrading to 4.7.0 from 4.6 should be possible with minimal or no changes to the Helm values. The following section identifies any caveats or recommendations that should be taken into account when upgrading.

helm upgrade --reuse-values not supported for upgrade from 4.6 to 4.7

Due to changes in the Chart's default values.yaml file, helm upgrade --reuse-values does not work. If you have a saved values file, use that when calling helm upgrade. If you don't have a saved values file, you can use helm get values to save the Helm values locally before calling helm upgrade.

helm get values <release-name> > release-values.yaml
helm upgrade <release-name> immuta/immuta -f release-values.yaml

Deprecated Helm Values

Some values have been deprecated in this release. The following table indicates the deprecated values and the migration path for each one. Update any custom Helm values referencing the deprecated values at the earliest convenience to avoid any issues when the deprecated values are removed.

Changes

• Update Kubernetes Batch API versions.

• Update Kubernetes Networking API versions.

• Update Kubernetes Policy API versions.

• Startup init container checks now have a time out.

• Support for disabling built-in database and using an external database.

• Database and Query Engine initContainers no longer run as root.

• Runtime user ID is now configurable for all Pods except Nginx Ingress.

• Added shared memory volume for Database and Query Engine by default.

• It is now possible to set a Docker image registry globally in Helm values.

• The environment variable noproxy will now be configured such that internal network connections do not use the proxy if extraEnv values are used to set HTTP_PROXY or HTTPS_PROXY.

• Added option to deploy Redis with TLS instead of Memcached for the cache.

Fix:

• Database and Query Engine Pods now crash and restart when the backup restore process fails.

• The TLS generation hook will now regenerate TLS certs if the externalHostname value changes.

4.6.12

This release makes it possible to increase the size of /dev/shm in the Database and Query Engine Pods. This functionality makes use of memory-backed emptyDir Volumes.

database:
  sharedMemoryVolume:
    enabled: true
queryEngine:
  sharedMemoryVolume:
    enabled: true

Changes

Update:

• Add support for memory-backed volumes to increase the size of /dev/shm.

• Update Helm Chart appVersion to 2021.3.5.

4.6.11

This release includes an update to the default image tag for the bundled Nginx Ingress Controller.

The ingress-nginx project has released a few updates since v0.47.0. This release updates the default version to v0.49.3, which includes an update to Alpine Linux v3.14.2. This update addresses CVE-2021-3711, which v0.47.0 was vulnerable to.

To upgrade the Nginx Ingress Controller without upgrading the Immuta Helm Chart, you can set the following Helm values.

nginxIngress:
  controller:
    imageTag: v0.49.3

Changes

Update:

• Update Helm Chart appVersion to 2021.3.4.

• Update ingress-nginx controller to v0.49.3.

4.6.10

This release updates the Immuta Helm Chart appVersion to 2021.2.2 and adds support for using an S3-compatible server for backup and restore. It also contains a fix for the metrics export CronJob in Immuta 2021.2+.

Using a Custom S3 Endpoint

In order to use a custom S3 endpoint for backup and restore, new Helm values have been added. The example below shows how to configure an S3 compatible endpoint.

backup:
  s3:
    # The endpoint URL of an s3-compatible server
    endpoint: s3-compatible.mycorp.com
    # The CA bundle in PEM format used to verify the TLS certificates of the endpoint
    caBundle: |
      -----BEGIN CERTIFICATE-----
      MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
      cm5ldGVzMB4XDTIxMDYzMDE1MTg0M1oXDTMxMDYyODE1MTg0M1owFTETMBEGA1UE
      AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMMR
      sFzDeAuCVy5JpkrCNp+A0zOrHX6BnTbDrzRV81Pfm2H6y8Pc3pASDgItiwqUBbeu
      fZ+5SAlZ2JY2O27mB1WM5Ajd5kSs7FausrHniSkKM+NlclPXXrBxcoli9UOEbo9T
      k+CrpV/I+EYYiMDKLT/tMX5AJSUavRHdb2n59bWEc2C1HTeBsr0jotn6zOHmhIAG
      O66SeCKjzR6MZ2TO8IWzGpqfY0a+QIqr4Z2Ihy+i6HvU3nXt2PVW5lQp5EN9Gmig
      g5x4re68paAmbU6FfeP9ruPoKjsQq5w70J/miPJb7TS59fdaWAM9yUS3ENG1hLZ7
      ALGIGJoUgy0QR/2DaV0CAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
      /wQFMAMBAf8wHQYDVR0OBBYEFLSraVnEIKrTomzE15ga4jSLdPuFMA0GCSqGSIb3
      DQEBCwUAA4IBAQBb5IcC45qcil48uSip7uBkfKPUFvQeTrq0Zg4zzYuNvdH+uDnH
      05Tz3k8dYBNyvIbh+TahCmmrUUyKgtvHeKrXfrqHoJwM7YTSIJTf7aVSEjBMtvjs
      4dnP3HoGOjJcXIadoZ5gvNUEepTQREu6/5j/Mq4F07UDhrYNZNMwdP3pXpadB9q3
      8fxjl88quJ4wWhq82hrwrGBv+z6oAoUbskvticWuu5eB8QkA3+tDQ5q1ZGjKGSqf
      G5xnXhHnQYy9J+JZ09JoySL3R5+959hJBC03Dwb38rLt/+Vkzdz8ILPT+PUyp5m4
      5KqYJfOVUzRqK0FJY67CkpFmi+4kuqgdGaGs
      -----END CERTIFICATE-----
    # Set to "true" to force the use of path-style addressing as opposed to hostname-style addressing
    forcePathStyle: true
    # Set to "true" to disable making an SSL connection to the endpoint
    #disableSSL:

Changes

Update:

• Update Helm Chart appVersion to 2021.2.2.

• Add blob storage endpoint support for backup storage.

Fix:

• Fix Metrics CronJob errors for Immuta 2021.2+

4.6.9

This release includes usability and stability improvements and an update to the bundled Nginx Ingress Controller. Usability improvements include the option to use an existing Kubernetes Secret for Immuta database passwords. Stability improvements include a change in configuration for the Immuta database and Query Engine StatefulSets.

Existing Kubernetes Secret

This release adds the option to use an existing Kubernetes Secret for Immuta database passwords used in the Helm installation. Using an existing Secret can be useful when you want more control over the creation of the Secret or do not want to include the sensitive values in the Immuta Helm values file.

To use an existing Kubernetes Secret, you must first create a Secret containing the required data keys.

Note: This is an example showing the required data keys and some sample values. For more details on creating Secrets in Kubernetes, see the Kubernetes Documentation.

apiVersion: v1
kind: Secret
metadata:
  name: existing-immuta-secret
type: Opaque
data:
  databasePassword: VUc5NWEySkxObWRXU0Rkbk4zQTNUQQ==
  databasePatroniApiPassword: b0hYY0RwWDNURUhQZ250VQ==
  databaseReplicationPassword: dzZyem9ndVgzYTZoRkVuMw==
  databaseSuperuserPassword: REZBUmg2VTdianBrVVRmZQ==
  queryEnginePassword: YTQyUHRoS3RvYUhOTDZFYg==
  queryEnginePatroniApiPassword: ZDNOZTNFb1FZaFU0UDNWTQ==
  queryEngineReplicationPassword: RWRXMlJEdmV6UjdFSkxVNA==
  queryEngineSuperuserPassword: N0tNelF3WEgzeFhHRHBwRw==

Reference the Secret by name in the Immuta Helm values.

existingSecret: existing-immuta-secret

If you have an existing release, you can migrate to an existing Kubernetes Secret by creating the Secret with the values previously defined in your Helm values by using the following mappings.

Set the existingSecret value and removing the password values from your Immuta Helm values file. Apply the change by running helm upgrade for your release, referencing the values file.

Database StatefulSet Configuration Update

This release includes a change in the default settings for Patroni, which is used in the database and Query Engine StatefulSets. This setting has been shown to improve the stability of the StatefulSets when the pods are restarted frequently due to cluster operations, such as node upgrades.

For new installations, no action is necessary to make use of this configuration change. For existing installations, the change must be applied manually to the StatefulSet pods.

kubectl exec -it RELEASE_NAME-immuta-database-0 -- patronictl edit-config --set postgresql.use_pg_rewind=true
kubectl exec -it RELEASE_NAME-immuta-query-engine-0 -- patronictl edit-config --set postgresql.use_pg_rewind=true

Note: Replace "RELEASE_NAME" with the name of your Immuta Helm release.

Nginx Ingress Controller Update

The ingress-nginx project released an update to mitigate a vulnerability in Nginx. We've updated the bundled ingress controller to this new release. More details are available in this GitHub issue.

Changes

Update:

• Add support for using an existing Kubernetes Secret for passwords.

• Enable use_pg_rewind for Patroni by default.

• Update ingress-nginx controller to v0.47.0 to mitigate CVE-2021-23017.

4.6.8

This release updates versions for various components.

Changes

Update:

• Update Helm Chart app version to 2021.2.0.

• Update immuta-deploy-tools image to 1.1.2.

• Update default ingress-nginx controller image to v0.46.0.

4.6.7

This release adds support for Immuta 2021.2 and to allow scaling Immuta web service pods to zero.

Changes

Update:

• Update container uid and gid in securityContext for 2021.2.

• Remove dependency on pgrep and getopt from scripts.

• Allow web pod replicas to be set to zero.

4.6.6

This release updates the default Immuta version to 2021.1.3 and the default memcached image tag to 1.6-alpine.

Changes

Update:

• Update memcached image to 1.6-alpine.

4.6.5

This release contains a fix for an issue where setting resource requests and limits was not possible for some containers created by the Immuta Helm Chart.

Changes

Fix:

• Set configurable resource limits for all containers and init containers

4.6.4

This release contains updates that enable the configuration of options that were previously not exposed in the Helm Chart.

New Features

The Immuta Fingerprint service configuration can now be set in Helm values. For example, to set the worker_timeout option to a value of 300, set the following values.

fingerprint:
  extraConfig:
    worker_timeout: 300

The log level for the Immuta Fingerprint service can also be configured. Valid values include DEBUG, INFO, WARNING, ERROR, and CRITICAL.

fingerprint:
  logLevel: DEBUG

Changes

Feature:

• Add ability to pass in configuration for Immuta Fingerprint service

4.6.3

Fix:

• Add port 8008 to Database and Query Engine Endpoints

4.6.2

Upgrade Notes

When upgrading to 4.6.2 with nginxIngress.enabled set to true, a new ConfigMap was introduced to be used by the NGINX Ingress Controller for leader election. This will cause the old ConfigMap, named ingress-controller-leader-immuta-<RELEASE>-ingress, to be orphaned. This will not affect the operation of Immuta and may be removed by running

kubectl delete configmap ingress-controller-leader-immuta-<RELEASE>-ingress

Changes

Fix:

• When using --reuse-values coming from 4.5.x charts, extraEnv value throws a templating error.

• Use Immuta config item publicPostgres.useSSL instead of publicPostgres.ssl starting with Immuta Version 2020.3.

• Adopt nginx-ingress leader election ConfigMap into the chart when using Optional Ingress Controller component.

Feature:

• Set log_error_verbosity = TERSE in Postgres configuration.

• Update default version to 2020.4.0.

• Add port 8008 to primary database and query-engine services.

• Add ability to set annotations on all service accounts.

• Set .spec.terminationGracePeriodSeconds for all Immuta pods.

• Update Query Engine readiness and liveness probes to use Patroni REST API endpoints.

• Update Database readiness and liveness probes to use Patroni REST API endpoints.

4.6.1

Changes

Fix:

• Database password is no longer used in Query Engine init-container.

4.6.0

Changes

Feature:

• Add support for LDAPS-backed Query Engine Authentication.

Fix:

• Web Service pods now wait for database migrations to execute before startup.

4.5.4

This release contains a fix for a race condition introduced in 4.5.3 when performing a new install.

Changes

Fix:

• Removed Endpoint resource for Database and Query Engine components to prevent race condition with Service. Endpoints are now created by Database and Query Engine Service resource.

4.5.3

This release contains a few fixes and updates the default Immuta application version to 2020.2.8.

Changes

Feature:

• Update appVersion to 2020.2.8.

Fix:

• Support EndpointSlices for Database and Immuta Query Engine in Kubernetes 1.17+.

4.5.2

This release contains a few fixes and updates the default Immuta application version to 2020.2.7.

Changes

Feature:

• Update appVersion to 2020.2.7.

• Update default values for Immuta Query Engine to support Elastic.

Fix:

• Helm hooks fail to run with helm older than 3.2.0.

• TLS Ciphers used in NGINX Ingress Controller incompatibility with default TLS cipher suites set in Databricks.

4.5.1

This release contains a fix for a bug introduced with the last release that caused helm install to timeout and fail when used with the --wait flag.

Upgrade Notes

If you are using Argo CD to deploy the Immuta Helm Chart, then you may notice that the TLS secret will be marked OutOfSync (requires pruning). The TLS secret (which is used for the encryption of inter-pod network traffic) should not be pruned. Update the Helm values with the following so that the TLS secret can be monitored as a resource without the risk of unwanted pruning.

tls:
  manageGeneratedSecret: true

Changes

Fixes:

• Fix issue with TLS generation and the helm install --wait flag.

4.5.0

New Features

Argo CD Support

The Immuta Helm Chart now supports deployment using Argo CD. Prior to this, the TLS generation hook would create a Secret that was not tracked by Helm. In Argo CD this resource would appear to need pruning. There was also an issue with the database and Query Engine endpoints, in which they would appear to be out of sync, but syncing them would remove the runtime changes that were being applied by Patroni. These issues have been resolved, and Argo CD is now supported.

For Argo CD versions older than 1.7.0 you must use the following Helm values in order for the TLS generation hook to run successfully.

hooks:
  tlsGeneration:
    hookAnnotations:
      helm.sh/hook-delete-policy: "before-hook-creation"

Starting with Argo CD version 1.7.0 the default Immuta Helm Chart values can be used.

Bundled Ingress Nginx Upgraded

The bundled version of ingress-nginx has been upgraded to 0.34.1. In addition to upgrading the default version, the cluster scoped resources that used to be created (ClusterRole and ClusterRoleBinding) are no longer required and have been removed.

Built-in Support for Azure LoadBalancer Annotations

Setting the Helm value nginxIngress.controller.service.isInternal will now cause an internal Azure load balancer to be created for nginx ingress.

Support Setting the externalTrafficPolicy

A new value was added to set the externalTrafficPolicy on the nginx ingress Service. Setting this value to "Local" can be useful for preserving client IP addresses. See the Kubernetes Documentation for more information on preserving the client source IP.

Upgrade Notes

When upgrading an existing Helm release from chart version <=4.4 that was using the default values tls.enabled=true and tls.create=true, you must first annotate and label the Immuta TLS Secret so that it can be adopted by Helm.

You will need to complete these steps if you encounter either of the following errors when running the helm upgrade command.

Error: UPGRADE FAILED: rendered manifests contain a resource that already exists.
Unable to continue with update: Secret "immuta-tls" in namespace "default" exists
and cannot be imported into the current release: invalid ownership metadata;
label validation error: missing key "app.kubernetes.io/managed-by": must be
set to "Helm"; annotation validation error: missing key
"meta.helm.sh/release-name": must be set to "immuta";
annotation validation error: missing key "meta.helm.sh/release-namespace":
must be set to "default"

Error: UPGRADE FAILED: rendered manifests contain a resource that already
exists. Unable to continue with update: Secret "immuta-tls" in namespace
"default" exists and cannot be imported into the current release: invalid
ownership metadata; label validation error: missing key
"app.kubernetes.io/managed-by": must be set to "Helm"

To resolve these upgrade errors, run the following commands, being sure to substitute the proper Helm release name and namespace.

kubectl annotate secret \
  -l app=immuta,component=generated-tls,release=<RELEASE_NAME> meta.helm.sh/release-name=<RELEASE_NAME> meta.helm.sh/release-namespace=<RELEASE_NAMESPACE>

kubectl label secret \
  -l app=immuta,component=generated-tls,release=immuta app.kubernetes.io/managed-by=Helm

After this, you can proceed to run helm upgrade.

Changes

Feature:

• Refactored Helm Chart hooks to work with Argo CD.

• Updated Helm Chart description.

• Update web pod annotations so that password changes cause a rolling restart.

• Upgrade ingress-nginx to 0.34.1.

• Support setting externalTrafficPolicy on the nginx ingress Service.

• Update nginx ingress Service to include Azure annotations.

Bug:

• Fix issue with release names that contain periods.

4.4.3

Changes

Bug:

• Fix fingerprint configuration when TLS is disabled.

4.4.2

New Features

Setting Global Pod Annotations and Labels

It is now possible to set pod annotations and labels at a global level. When set, these labels and annotations will be used for all pods that the Immuta Helm Chart creates. Pod labels and annotations can be set using the Helm values global.podAnnotations and global.podLabels to a map of string to string.

global:
  # annotations to be added to every pod
  podAnnotations:
    example.org/latest-configuration: 3d0726f97faa2e4482d7bd31114a26c3976ed96dba5804d951bf480a6af8810c
  # labels to be added to every pod
  podLabels:
    example.org/team: "alpha"

Labels and annotations can also be set individually for each component in the Immuta Helm Chart. To set labels and annotations for an individual component, set the Helm values <componentName>.podAnnotations and <componentName>.podLabels to a map of string to string.

web:
  podAnnotations:
    example.org/latest-configuration: 3d0726f97faa2e4482d7bd31114a26c3976ed96dba5804d951bf480a6af8810c
  podLabels:
    example.org/team: "alpha"
queryEngine:
  podAnnotations:
    example.org/latest-configuration: 7c6f707ce995b34b9a09a4df6f0b20e8580914f65b5117b10318a35a465a3aa8
  podLabels:
    example.org/team: "beta"

Changes

Feature:

• Support labels/annotations on all pods.

Bug:

• Fix for Query Engine pod referencing image repository from database values.

4.4.1

Changes

Cleanup:

• Remove the option to configure Data Source CA certificates using a ConfigMap.

4.4.0

New Features

Support for Custom nodeSelector and tolerations

It is now possible to set custom nodeSelector and tolerations for each component in the Immuta Helm Chart.

To set a custom nodeSelector, set the Helm value for <componentName>.nodeSelector to a valid nodeSelector. See the Kubernetes documentation for more details.

web:
  nodeSelector:
    lifecycle: spot
database:
  nodeSelector:
    lifecycle: on-demand

To set a custom tolerations, set the Helm value for <componentName>.tolerations to a valid tolerations. See the Kubernetes documentation for more details.

web:
  tolerations:
  - key: lifecycle
    operator: Equal
    value: spot
    effect: NoSchedule
database:
  tolerations:
  - key: lifecycle
    operator: Equal
    value: on-demand
    effect: NoSchedule

Changes

Feature:

• Support setting nodeSelector and tolerations on all pods.

Release Lifecycle Schedule

Release Lifecycle Terms

• 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.

Long Term Support (LTS) Policy

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.

FAQ

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.

Design partner

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

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

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.

Generally available (GA)

GA features are complete and available to all customers. Full SLA targets and processes apply.

Use the image digests below to verify the integrity of Immuta images that you pull.

The table below outlines the available features currently in preview for this release and when they were introduced.