Skip to main content

v2.24.0

Date of release: 30/10/2026

Engine version: 16.12.1

Conform version: 1.3.1

Foresight version: 1.6.0

Genesis version: 0.11.0

We appreciate your continued support and value your feedback. If you encounter any issues or have any questions, please don't hesitate to contact our support team.

Fixes and improvements​

  • Genesis is upgraded to 0.11.0. Genesis 0.11.0 removes the allow-changes setting from the extendedFormatSettings policy section, and Halo now refuses a policy that contains it. Read the Genesis notice under Upgrade notices before you upgrade.
  • Halo now checks an extendedFormatSettings policy against the full Genesis 0.11.0 policy rules when you save the policy, and applies the same checks when you send a policy with a file. Previously, some settings that Genesis refuses passed these checks, and every NITF or NSIF file processed with that policy then failed. Overrides accept only the formats that Genesis processes in a NITF file: nitf, jpeg, jpeg2000, sidd, h264, h265, wmf and emf. When a policy breaks these rules, Halo returns a 400 response with error code 4004 that names the setting.
  • Saving a policy in the Portal no longer deletes its extendedFormatSettings section. Previously, a Portal save removed the NITF and NSIF settings, and Genesis then used its default rules.
  • Halo now reports a NITF or NSIF file as protected only when Genesis writes a protected file. When Genesis fails because of an internal processing error, Halo returns an error and does not bill the file.
  • The ICAP server now reads each chunk of an upload by its declared size. Previously, the server found the end of an upload by searching for the bytes that end a chunked body, so a file that contained those bytes ended the upload early and the server did not send the file for protection. The server also no longer keeps each whole upload in memory. Six 500 MB uploads at the same time now need less than 4 GiB.
  • The ICAP server now opens its mutual TLS port on hosts that enforce FIPS. Previously, the server could not load its certificate on these hosts, because the certificate load used 3DES encryption, which FIPS refuses. The server then served only the plain ICAP port.
  • A Policy API or RabbitMQ outage no longer restarts every ICAP server pod. The liveness probe now checks only the ICAP listener. The readiness probe still checks the Policy API and RabbitMQ, so Kubernetes sends no ICAP traffic to the pods until both services are available again.
  • Storage Monitor now has 70 seconds to start before Kubernetes restarts it. Previously, with the Outlook banner on, the Exchange Online setup took about 12 seconds, and Kubernetes often restarted the pod during the setup.
  • Storage Monitor now stays running when Microsoft Graph rejects its credentials, for example after a client secret expires. Previously, the pod restarted repeatedly. When the connection fails for a different reason, such as a network outage, Storage Monitor tries again after 5 minutes and doubles the wait after each failure, up to 1 hour.
  • Storage Monitor now logs a failed Outlook banner setup or distribution list sync as a failure. Previously, the log reported success after some of these failures.
  • On AKS, EKS and GKE, the RabbitMQ cluster operator install command now lets the Kubernetes API server reach the operator webhook on port 9443. Previously, on a cluster that enforces NetworkPolicy, the operator chart's NetworkPolicy blocked the webhook and the RabbitMQ deployment failed. See AKS Step 7, EKS Step 6 and GKE Step 7.
  • The cdrplatform-storage chart has a new azure.skuname value that sets the Azure Files SKU. The default is Premium_LRS, as before.
  • The engine image no longer contains brotli 1.0.9, which has the vulnerability CVE-2026-111497. The engine now uses brotli 1.2.1 from its base image.
  • Third-party components are updated, including RabbitMQ 4.3.7, Prometheus 3.15.1, External Secrets 2.14.0 and the Azure CSI drivers. The Halo install scripts now deploy each third-party image by its digest as well as its tag. Service dependencies are also updated to fix known vulnerabilities.

Upgrade notices​

Expand the notices for the version you are upgrading from.

Versions before v2.24.0

Genesis 0.11.0 policy notice​

Genesis 0.11.0 removes the allow-changes setting from the cdr section of extendedFormatSettings. Halo v2.24.0 refuses a policy that sets allow-changes at any level, when you save the policy and when you send it with a file. If a saved policy still contains allow-changes, every NITF or NSIF file processed with that policy fails, and you cannot save that policy in the Portal.

After you upgrade, remove allow-changes from each saved policy that has an extendedFormatSettings section, then save the policy through the API. Policies without an extendedFormatSettings section need no action.

Versions before v2.23.0

RabbitMQ 4.3 upgrade notice​

Halo v2.23.0 upgrades RabbitMQ to 4.3, which RabbitMQ supports upgrading to in place only from 4.2. Halo v2.17.0 was the first release on RabbitMQ 4.2.

  • From Halo v2.17.0 or later, run the usual upgrade. The cdrplatform-rabbitmq chart moves RabbitMQ's metadata to Khepri before the upgrade, as RabbitMQ recommends.
  • From a release before v2.17.0, upgrade to a release from v2.17.0 to v2.22.x first. A RabbitMQ 4.0 or 4.1 cluster upgraded straight to 4.3 breaks and cannot be rolled back, so the chart refuses the upgrade before RabbitMQ changes. kubectl logs -n cdrplatform job/rabbitmq-khepri-migration shows the reason.

This release also upgrades the RabbitMQ cluster operator to 2.23.0, which no longer allows the cdrplatform-rabbitmq chart's earlier root init container. Upgrade the cdrplatform-rabbitmq chart before the rabbitmq-cluster-operator chart. If the operator is upgraded first, RabbitMQ stops until the cdrplatform-rabbitmq upgrade runs, so run it straight away. The upgrade removes the old init container and restarts RabbitMQ in either order. If that upgrade fails, kubectl logs -n cdrplatform job/rabbitmq-root-init-removal shows the reason.

RabbitMQ 4.3 cannot be rolled back to 4.2 in place. Rolling back to an earlier Halo release means restoring the RabbitMQ data taken before the upgrade. See the RabbitMQ 4.3 release post for details of the move to Khepri.

Versions before v2.22.0

MongoDB operator upgrade notice​

Starting Halo v2.22.0, in-cluster MongoDB is managed by MongoDB Controllers for Kubernetes (MCK, the mongodb-kubernetes chart) in place of the deprecated MongoDB Community Operator (community-operator). This applies only if you run MongoDB inside the cluster. Deployments backed by DocumentDB, Cosmos DB or another external MongoDB are unaffected and need no action.

If you run MongoDB inside the cluster, uninstall the Community Operator first, then install MCK. Your data is preserved if the MongoDBCommunity CRD carries the retain annotation before the uninstall.

Add the MongoDB Helm repository if you have not already:

helm repo add mongodb https://mongodb.github.io/helm-charts
helm repo update

Then, on a cluster running in-cluster MongoDB:

# Protect the data: this annotation stops the uninstall cascading to the CRD, replica set and volumes
kubectl annotate crd mongodbcommunity.mongodbcommunity.mongodb.com helm.sh/resource-policy=keep --overwrite

# Remove the old Community Operator
helm uninstall community-operator -n cdrplatform

# Install MongoDB Controllers for Kubernetes
helm install mongodb-kubernetes-operator mongodb/mongodb-kubernetes -n cdrplatform --version 1.12.0

# Redeploy the MongoDB chart (use the same cloud_provider you deployed with)
helm upgrade -i cdrplatform-mongodb cdrplatform-mongodb -n cdrplatform --atomic --set cloud_provider=<provider>

MCK adopts the existing replica set in place and rolls the MongoDB pod once. Confirm the pod is Ready and the data is intact before continuing the upgrade.

ICAP server upgrade notice​

The ICAP server is now operated from the portal: mutual TLS moved out of the chart's configuration block and became a setting an administrator can change, and starting and stopping the server moved there too. Four things need attention when upgrading an existing ICAP install.

configuration.ENABLE_MTLS was replaced by settings.ICAP.MutualTlsEnabled. The chart fails the render on the old key, naming the replacement, rather than accepting it and ignoring it. Update any values overlay or saved helm upgrade command before upgrading:

--set settings.ICAP.MutualTlsEnabled=true

The certificate volume is now always mounted, so enabling mutual TLS no longer changes the pod specification. It still takes effect on the next ICAP server restart, because the listener binds its port at startup. While mutual TLS is off the server does not bind the TLS port at all, where earlier versions bound it and refused every connection, so a port scan of an appliance without certificates no longer reports that port as open.

The ICAP server pod now runs as its own service account, so that it can write its settings to its own ConfigMap, where it previously ran as default. Anything in the namespace bound to default (a workload-identity annotation, an image-pull secret, a NetworkPolicy or an RBAC rule naming it) has to be reapplied to the new account. Set the annotations on the new account:

--set serviceAccount.annotations.<key>=<value>

Or keep the account the install already uses:

--set serviceAccount.name=<existing-account>

The ICAP server is now started and stopped from the Portal. Open Protection settings, click the ICAP tab and use the control under ICAP configuration. The appliance ships with the ICAP server installed but not running, and nothing answers on the ICAP ports until an administrator turns it on. The ICAP settings on that tab can be changed only while the server is on.

Stop the ICAP server once after your first upgrade if you were not running it. The chart no longer fixes the number of ICAP servers, so that the Portal control keeps whatever you set across later upgrades. Upgrading a release installed from an earlier chart starts the server once as part of that change, whatever state it was in beforehand:

kubectl scale deploy icap-server -n cdrplatform --replicas=0

Only the first upgrade needs this. A freshly imaged appliance is unaffected.

Versions before v2.9.0

RabbitMQ upgrade notice​

Starting Halo v2.9.0, the RabbitMQ version is upgraded from 3.13 to 4.x. When upgrading from an older version of Halo to any version above 2.9.0 all stable RabbitMQ feature flags should be enabled before performing the usual upgrade process using the following command:

rabbitmqctl enable_feature_flag all
Versions before v2.6.2

Deprecation notice​

The cdrplatform-metrics-collation service was deprecated and removed in release 2.6.2. When you upgrade to 2.6.2 or later, uninstall the cdrplatform-metrics-collation Helm chart using this command:

helm delete cdrplatform-metrics-collation -n cdrplatform
Service versions (image tags)
ServiceContainer RepositoryVersion
cdrplatform-engineglasswallhub.azurecr.io/cdrplatform-engine2.24.0-218622
cdrplatform-sync-apiglasswallhub.azurecr.io/cdrplatform-sync-api2.24.0-218622
cdrplatform-report-extractorglasswallhub.azurecr.io/cdrplatform-report-extractor2.24.0-218622
cdrplatform-portalglasswallhub.azurecr.io/cdrplatform-portal2.24.0-218622
cdrplatform-policy-apiglasswallhub.azurecr.io/cdrplatform-policy-api2.24.0-218622
cdrplatform-api-accessglasswallhub.azurecr.io/cdrplatform-api-access2.24.0-218622
cdrplatform-portal-accessglasswallhub.azurecr.io/cdrplatform-portal-access2.24.0-218622
cdrplatform-license-managementglasswallhub.azurecr.io/cdrplatform-license-management2.24.0-218622
cdrplatform-cleanupglasswallhub.azurecr.io/cdrplatform-cleanup2.24.0-218622
cdrplatform-async-apiglasswallhub.azurecr.io/cdrplatform-async-api2.24.0-218622
cdrplatform-metrics-projectionglasswallhub.azurecr.io/cdrplatform-metrics-projection2.24.0-218622
cdrplatform-tally-accumulatorglasswallhub.azurecr.io/cdrplatform-tally-accumulator2.24.0-218622
icap-serverglasswallhub.azurecr.io/icap-server2.24.0-218622
cdrplatform-rabbitmqglasswallhub.azurecr.io/cdrplatform-rabbitmq2.24.0-218622
cdrplatform-storage-monitorglasswallhub.azurecr.io/cdrplatform-storage-monitor2.24.0-218622
Prompt Injection Detection APIglasswallhub.azurecr.io/pulsar/detection2.24.0-218622
Helm chart versions
ChartChart RepositoryVersion
cdrplatform-rabbitmqglasswallhub.azurecr.io/helm/cdrplatform-rabbitmq0.9.8
cdrplatform-external-secretsglasswallhub.azurecr.io/helm/cdrplatform-external-secrets0.8.0
cdrplatform-storageglasswallhub.azurecr.io/helm/cdrplatform-storage0.8.3
cdrplatform-engineglasswallhub.azurecr.io/helm/cdrplatform-engine0.6.3
cdrplatform-sync-apiglasswallhub.azurecr.io/helm/cdrplatform-sync-api0.4.3
prometheus-scalingglasswallhub.azurecr.io/helm/prometheus-scaling0.3.1
cdrplatform-portalglasswallhub.azurecr.io/helm/cdrplatform-portal0.4.4
cdrplatform-policy-apiglasswallhub.azurecr.io/helm/cdrplatform-policy-api0.3.3
cdrplatform-api-accessglasswallhub.azurecr.io/helm/cdrplatform-api-access1.5.0
cdrplatform-portal-accessglasswallhub.azurecr.io/helm/cdrplatform-portal-access0.7.0
cdrplatform-license-managementglasswallhub.azurecr.io/helm/cdrplatform-license-management0.4.0
cdrplatform-cleanupglasswallhub.azurecr.io/helm/cdrplatform-cleanup0.4.0
cdrplatform-async-apiglasswallhub.azurecr.io/helm/cdrplatform-async-api0.2.5
cdrplatform-metrics-projectionglasswallhub.azurecr.io/helm/cdrplatform-metrics-projection0.2.3
cdrplatform-report-extractorglasswallhub.azurecr.io/helm/cdrplatform-report-extractor0.2.2
cdrplatform-tally-accumulatorglasswallhub.azurecr.io/helm/cdrplatform-tally-accumulator0.2.5
cdrplatform-mongodbglasswallhub.azurecr.io/helm/cdrplatform-mongodb0.3.2
icap-serverglasswallhub.azurecr.io/helm/icap-server2.2.3
cdrplatform-storage-monitorglasswallhub.azurecr.io/helm/cdrplatform-storage-monitor0.5.1
cdrplatform-pulsarglasswallhub.azurecr.io/helm/cdrplatform-pulsar0.1.0

Documentation​

Swagger documentation Glasswall documentation Clean a file Archive support License management

Last updated on