Ververica Platform 3.1.4

Release Date: 2026-10-13

Ververica Platform 3.1.4 is a feature release focused on access control and installation hardening, including operator-defined custom namespace roles, engine artifacts served from your own blob storage, and bug fixes across role bindings, API tokens, SQL validation, and log retrieval on Azure.

New Features and Improvements

Custom Namespace Roles

Ververica Platform 3.1.4 supports custom namespace roles, defined as a set of permission codes, either derived from a built-in role with codes added or removed, or as a complete list. A custom role is bound like a built-in role, and a user who holds several roles in one namespace receives the combined permissions. Roles are created and changed through the API; in the Console, custom roles appear in the role picker on the Members page.

For more information, see Custom Namespace Roles.

Engine Artifacts Served from Your Blob Storage

Ververica Platform 3.1.4 keeps the engine artifacts (engine archives, connectors, and engine SDKs) in the installation's own blob storage (global.blobStorage.baseUri) and reads them from there, instead of serving them from a separate in-cluster HTTP service. The Application Manager uploads them each time it starts, so install and upgrade remain a single helm upgrade --install. The in-cluster vera service is no longer deployed. The engine artifacts of VERA 4.5 and VERA 4.6 take about 25 GiB, so make sure that your blob storage has enough free space before you install or upgrade.

For more information, see Engine Artifacts in Blob Storage.

VERA 4.6

Ververica Platform 3.1.4 adds the VERA 4.6 engine, available with JDK 11 and JDK 17 alongside VERA 4.5. Ververica Platform 3.1.4 ships VERA 4.6.1, which bundles the OpenTelemetry metric reporter.

For more information, see VERA 4.6.

Apply Deployment Defaults When Editing a Deployment

A new toggle in the deployment editor applies the current namespace Deployment Defaults to an existing deployment. Enabling it restarts the job with the updated settings.

YAML Tab for Batch Deployments

Batch deployments now show the YAML tab in the deployment configuration view, matching streaming deployments.

Restore Strategy Note on High Availability

The Restore Strategy field now explains that restoring from a checkpoint requires high availability to be enabled.

Credentials from Kubernetes Secrets by Default

The Helm chart now delivers the metadata database password to every platform component through Kubernetes Secrets, instead of writing it into ConfigMaps or pod environment variables. To use an existing Secret, set global.database.passwordSecret to its name. The password is read from the key password, which you can change with global.database.passwordSecretKey. If you don't set global.database.passwordSecret, the chart creates a Secret for each component from global.database.password. The OIDC client secret of the access control service also moves from a ConfigMap into a Secret. To use an existing Secret, set access-control.client.clientSecretSecret. The key defaults to clientSecret and you can change it with access-control.client.clientSecretSecretKey. Existing values keep working without changes. When you change a value in an existing Secret, the pods don't restart automatically, so restart the components that use it.

No Hardcoded Credentials in Helm Chart Templates

The Helm chart templates no longer contain hardcoded credentials. The values now come from Helm values or from Secrets that you provide. Some of these values have defaults that are meant for development only, so set your own values for production:

• Request-signing secret shared by vvp-gateway, vvp-meta, and vvp-premise. It is stored in a single Secret, vvp-sign-secret. The default value of global.signSecret is the same in every installation. To use your own Secret, set global.signSecretSecret. The key defaults to signSecret and you can change it with global.signSecretSecretKey.
• OIDC client secret of the access control service, which defaults to clientSecret. See Credentials from Kubernetes Secrets by Default.
• OIDC client settings of the SQL Service, which are now Helm values under vvp-appagent.sqlService.oidc. Installation fails if you turn on vvp-appagent.sqlService.oidc.enabled without a client secret. To reference an existing Secret, set vvp-appagent.sqlService.oidc.clientSecretSecret.

A new global.timezone value sets the time zone of the vvp-meta and vvp-premise components, which earlier versions hardcoded to Asia/Shanghai. It defaults to UTC. To keep the earlier time zone, set global.timezone to Asia/Shanghai.

Restricted Service Account Permissions

Platform components that don't call the Kubernetes API no longer mount a service account token: access-control, vvp-advisor, vvp-autopilot, vvp-fluss-manager, vvp-meta, and vvp-premise. The Application Manager and gateway service accounts can now only create and list Secrets in their own namespace, and no longer receive Secret permissions in the namespaces listed in rbac.additionalNamespaces.

Bug Fixes

Namespace-Scoped Role Bindings Granted Workspace Access

Ververica Platform 3.1.4 fixes an issue where creating a role binding through POST /rbac/roleBindings with a namespaceId ignored the namespace and granted the role on the whole workspace.

Review role bindings created through the API before the upgrade, and recreate any that were meant to be namespace-scoped.

Internal Server Error with New Namespace API Tokens

Ververica Platform 3.1.4 fixes an issue where a newly created namespace API token returned a 500 Internal Server Error on ordinary API calls instead of being authorized.

Consistent Role Names in the Console

Ververica Platform 3.1.4 fixes inconsistent role names across Console views, where a member added as admin appeared as owner on other screens, owner bindings couldn't be managed, and members were shown as OIDC subject IDs instead of names.

Validate Fails Batch Drafts with a Filesystem Sink

Ververica Platform 3.1.4 fixes an issue where Validate failed with a storage credential error for batch drafts that write to a remote path (s3://, abfss://) with the filesystem connector, although the job deployed and ran correctly.

Missing Logs of Failed Jobs on Azure

Ververica Platform 3.1.4 fixes log retrieval on Azure, where archived JobManager and TaskManager logs were stored in blob storage but the log listing returned nothing.

Masked Per-Bucket S3 Access Keys

Ververica Platform 3.1.4 masks per-bucket S3 access keys (s3.bucket.<bucket>.access.key) in logs and the Flink configuration view, alongside the keys that were already masked. Both VERA 4.5.4 and VERA 4.6.1, the engines available with Ververica Platform 3.1.4, are patched.

Credentials in Platform Component Logs

Ververica Platform 3.1.4 fixes an issue where the Application Manager, agent, and SQL Service logs contained credentials in plain text, including secret values and credentials set in the Flink configuration of a deployment.

VERA Engine Hotfixes 4.5.4 and 4.6.1

Ververica Platform 3.1.4 ships the VERA 4.5.4 and VERA 4.6.1 engine hotfixes. VERA 4.5.4 replaces VERA 4.5.2 for the VERA 4.5 engine versions. Both hotfixes fix the following issues:

• YAML CDC jobs from MySQL to Apache Paimon or Apache Iceberg failed with class loading errors unless classloader.resolve-order was set to parent-first.
• Creating a Unity Catalog connection with the Delta catalog failed.
• Reading Parquet files with ARRAY<ROW<...>> columns failed with an IndexOutOfBoundsException, although writing them succeeded.
• The Kafka Schema Registry catalog didn't pass the avro-confluent.properties.* credentials to its own client, so describing or querying catalog tables failed with 401 Unauthorized against an authenticated Schema Registry.
• The fixes described in Validate Fails Batch Drafts with a Filesystem Sink and Masked Per-Bucket S3 Access Keys are also part of both hotfixes.

Vulnerability Fixes (Inside Apache Flink®)

• Removed pip to address CVE-2023-5752, CVE-2025-8869, CVE-2026-13346, CVE-2026-1703, CVE-2026-3219, CVE-2026-6357, CVE-2026-8643
• Updated com.fasterxml.jackson.core:jackson-core to 2.17.2 to address GHSA-r7wm-3cxj-wff9
• Updated setuptools to 81.0.0 to address CVE-2025-47273

Vulnerability Fixes (Outside Apache Flink®)

• Updated org.apache.tomcat.embed:tomcat-embed-core to 10.1.59 to address CVE-2026-65182, CVE-2026-65905, CVE-2026-68525

Upgrade

To upgrade Ververica Platform to version 3.1.4, run the following Helm command:

1helm upgrade --install <RELEASE_NAME> \
2  oci://registry.ververica.cloud/platform-charts/ververica-platform \
3  --version 3.1.4 \
4  --namespace vvp-system \
5  --values values.yaml

If you upgrade from Ververica Platform 3.1.3 or earlier and the SQL Service volume (PVC vvp) is smaller than 30 GiB, add --set vvp-appagent.persistentVolume.size=30Gi to this command to increase it to the 30 GiB that VERA 4.6 needs. The storage class of the volume must support volume expansion.