This article covers upgrading an on-premises Cequence Unified API Protection (UAP) platform installation from release 8.7.x to release 9.2.0, and rolling back if needed. This upgrade spans two major version boundaries at once. It carries the API Security v2 component migration introduced in release 9.x, moves the platform's Kafka message bus off ZooKeeper and onto KRaft, and moves Airflow from 2.x to 3.x. All three changes recreate underlying infrastructure or data rather than migrating it in place, so read this article fully before you begin.
SaaS-hosted environments are upgraded by Cequence directly. This article is for on-premises installations using Helm.
Before you upgrade to release 9.2.0
Complete the following before starting the upgrade.
Export your current configuration. Custom risk rules and custom discovery patterns are deleted during this upgrade and are not otherwise preserved, and the Airflow metadata database and Kafka cluster are both replaced rather than migrated. Anything you need to retain must be exported first.
Data loss: Custom risk rules and custom discovery patterns. These are deleted during the upgrade and are only recoverable by importing your exported configuration afterward.
Data loss: Airflow run history. DAG run history, task history, connections, variables, and users do not carry over this upgrade. If you need to preserve this history, export it before you begin. Machine-learning model configurations themselves are unaffected.
Data loss: Kafka topic data. The Kafka cluster is rebuilt, not migrated, as part of this upgrade. Topic data does not carry over. This is expected and does not affect UAP functionality, because configuration lives in Elasticsearch and republishes to Kafka automatically when components start.
Upgrading to release 9.2.0
Complete the steps in order. Each step depends on the one before it.
- Export all current configuration, if you have not already done so as part of the prerequisites above.
- Apply the Strimzi 0.51.0 custom resource definitions (CRDs) to your cluster, server-side.
- Upgrade the Strimzi operator to release 0.51.0.
Run the Helm upgrade to release 9.2.0.
The upgrade recreates pods across the platform as it proceeds, including a full component swap in the API Security path. Monitor the rollout and verify that each component reaches a healthy state before considering the upgrade complete.
After the upgrade completes, the platform is running release 9.2.0 with the API Security v2 components, Kafka on KRaft, and Airflow on 3.x. Continue to the verification steps below.
Component changes
Release 9.2.0 replaces several release 8.7.x components as part of the API Security v2 migration, in addition to the Kafka and Airflow changes.
| Removed in release 9.2.0 | Replaced by |
traffic-analyzer | risk-engine |
resource-dictionary | api-service |
resource-dictionary-metrics-curator | api-service |
resource-dictionary-metrics-migrator | api-service |
spec-parser | api-service |
sde-service | risk-engine |
sentinel/elasticsearch-users | Not applicable |
kafka-zookeeper-* | kafka-4-controllers-* |
kafka-* | kafka-4-kafka-* |
airflow-webserver | airflow-api-server |
New components appear alongside these changes: validation-service and ai-assistant join the API Security path, and tempo, otel-collector, and minio support the platform's observability stack.
Configuration value changes
The following Helm chart values change between release 8.7.x and release 9.2.0. Old key names still exist in values.yaml for backward compatibility, but release 9.2.0 does not read them, so anything left in the old location is silently ignored rather than raising an error.
| Release 8.7.x value | Release 9.2.0 value | Change |
airflow.airflowVersion: "2.11.0" | airflow.airflowVersion: "3.3.0" | Airflow major version |
airflow.webserver | airflow.apiServer | The webserver component is replaced by api-server, which serves both the UI and the REST API at /api/v2/. |
airflow.ingress.web | airflow.ingress.apiServer | The new block defaults to enabled: false and an empty ingressClassName. Set both explicitly, or the Airflow UI is unreachable after the upgrade. |
airflow.config.api.auth_backends | Removed | Release 9.2.0 handles API authentication differently. Delete this key from your overrides. |
airflow.config.elasticsearch.log_id_template using {execution_date} | Uses {run_id} | Template becomes {dag_id}_{task_id}_{run_id}_{try_number}. |
| Not present | airflow.config.elasticsearch.write_to_es: 'True' | New. Task logs write to Elasticsearch. |
| Not present | airflow.config.elasticsearch.target_index | New. Defaults to a daily index of the form airflow-filebeat-<date>. |
| Not present | airflow.jwtSecretName: airflow-api-auth-jwt-secret | New. Shared JWT signing key used by the scheduler, api-server, and workers. |
| Not present | airflow.apiSecretKeySecretName: airflow-api-secret-key | New. |
| Not present | airflow.apiAuthJwtSecretConfig | New. Leave the secret value empty to generate and persist one automatically. |
| Not present | airflow.apiServerUrl: "" | New. An empty value derives the URL from the release name. Consumed internally as AIRFLOW_API_BASE_URL. |
sentinel.trafficAnalyzer.discoveryAllowedResponseCodes | sentinel.riskEngine.discoveryAllowedResponseCodes | Same purpose, renamed to match the trafficAnalyzer-to-riskEngine component swap. Sets additional response codes to admit for discovery beyond the default 2xx and 3xx range. |
Release 9.2.0 also introduces a cap on issue creation per risk rule, defaulting to 1,000. Once a rule reaches the threshold, new issue creation for that rule pauses, though the risk stays visible in your inventory rather than being hidden. The list view and risk details page show an indicator when a rule hits the cap. Configure the threshold through apiService.issueCap.threshold.
Verifying the upgrade
Verify the following after the upgrade completes and before you consider it finished.
- Verify that the components listed as removed above are gone, and that their replacements are running and healthy.
- Verify that
kafka-4-kafka-*,kafka-4-entity-operator-*,kafka-4-kafka-exporter-*, andkafka-4-connect-*are all healthy. These are the renamed equivalents of the release 8.7.x Kafka pods. - Check the
spec-migration-statusindex for any documents withstatus: failed. These identify specific API specs that need manual fixup after the migration, such as specs referencing undefined security schemes. - Check system logs across the platform for errors or warnings.
Several areas of the UI show empty or reduced data immediately after the upgrade: API Inventory and Endpoints, Risk Posture, and the System Usage Dashboard. This data is not deleted. The old Elasticsearch indices remain in place, but the new release 9.2.0 components read from new indices instead. If you roll back, the old components resume reading from the original indices and this data reappears.
If endpoint table columns are not visible after the upgrade, this is usually a stale endPointColumnPref entry in your browser's local storage rather than a platform issue. Open your browser's developer tools, go to Application, then Local Storage, delete the endPointColumnPref entry, and reload the page.
Once verification passes, monitor system performance for a few hours before considering the upgrade complete. Watch for error logs or unusual behavior during this window.
Rolling back to release 8.7.x
- Downgrade the Strimzi operator to release 0.45.2.
Run the Helm upgrade specifying your release 8.7.x version.
Monitor the downgrade as components revert. If
airflow-webserverenters a crash loop during this step, delete the pod. It recovers on restart.- Downgrade the Strimzi CRDs to release 0.45.2.
- Import the configuration you exported before the upgrade.
Verifying the rollback
- Verify that all pods are running.
- Verify that the platform version shows your release 8.7.x version.
- Verify that Kafka is back on ZooKeeper. The
kafkaresource should be ready on Kafka 3.9.1, withkafka-zookeeper-*andkafka-kafka-*pods running. - Check system logs for errors or warnings.
Rolling back restores API Inventory and Endpoints, Risk Posture, Issues, and the System Usage Dashboard automatically, because the release 8.7.x components point back at their original indices. Custom risk rules and custom discovery patterns deleted during the upgrade are restored through the configuration import in the last step, not automatically.
Rolling back also rolls Airflow back to 2.x. The airflow-api-server and airflow-dag-processor pods are removed and airflow-webserver returns. Any Airflow values you moved to apiServer or ingress.apiServer for release 9.2.0 need to move back under webserver and ingress.web for the Airflow UI to be reachable after the rollback.