Skip to main content
Version: 3.1

Ververica Platform 3.1.1

Release Date: 2026-06-19

Ververica Platform 3.1.1 is a maintenance and feature release focused on access control, Kubernetes flexibility, and infrastructure choice. This update restores group-based access control from Ververica Platform 2.x, adds Active Directory group support, introduces PostgreSQL as a supported metadata database alongside MySQL, and enables Azure Blob Storage access through Workload Identity. This release also adds custom pod and namespace-level annotations for Kubernetes deployments, completes custom savepoint loading through the UI, renames the custom resource definition to allow co-installation of Ververica Platform 2.x and Ververica Platform 3.x, and adds global security context configuration to the Helm chart.

New Features and Improvements​

Group-Based Role Mapping​

Ververica Platform restores group-based access control for OIDC and SAML identity providers, matching the capability available in Ververica Platform 2.x. Administrators can now map IdP groups to platform roles using groupsClaim (OIDC) or identity-provider.groups-attribute (SAML) in the Helm chart authentication configuration, and bind groups to roles by adding userId: "group:<group-id>" entries in initialAccessFileContent.initialAccess.

Group-to-role bindings support the four preset roles (viewer, editor, owner, admin) at workspace and namespace scope. On each authenticated request, the platform resolves the user's IdP-supplied groups and grants the union of matched roles.

This removes the need to manage individual user entries for access control and restores the scalable access model required for larger organizations. For configuration details, including provider-specific examples for Azure Entra ID, AWS Cognito, and SAML, see Access Control.

Azure Blob Storage Workload Identity​

Ververica Platform 3.1.1 now supports Azure Workload Identity for accessing Azure Blob Storage, removing the need for static credentials such as storage account keys or connection strings. This authentication method links Kubernetes service accounts to Azure Active Directory identities, allowing Flink jobs to read from and write to Blob Storage without manually managed secrets.

This is particularly relevant for organizations running on AKS with zero-trust or managed-identity requirements. Workload Identity was supported in Ververica Platform 2.x and is now restored in Ververica Platform 3.x, replacing the static Microsoft ABS credential method available in Ververica Platform 3.0.

PostgreSQL Database Support​

Ververica Platform now supports PostgreSQL as a metadata database for platform persistence, in addition to the existing MySQL option. This allows organizations that standardize on PostgreSQL or use managed PostgreSQL services to run Ververica Platform without provisioning a separate MySQL instance.

For more information, see PostgreSQL as Metadata Store.

Namespace-Level Annotations​

Ververica Platform now supports namespace-level annotations for Flink deployments. Annotations defined at the namespace level apply to all JobManager and TaskManager pods within that namespace, removing the need to configure them individually per deployment.

Namespace-level annotations are defined through jobManagerPodTemplate.metadata.annotations and taskManagerPodTemplate.metadata.annotations. Annotations follow a merge precedence where deployment-level settings take precedence over namespace-level settings.

For more information, see Namespace-Level Annotations.

Custom Pod Annotations and Log Level Configuration​

The Helm chart now supports custom pod annotations through global.podAnnotations in values.yaml, restoring the configuration option available in Ververica Platform 2.x. This allows operators to inject annotations into all platform pod templates for integration with log collectors, service meshes, vault injectors, and other Kubernetes-native tooling.

This release also exposes global.logLevel as a Helm value, allowing operators to control the logging verbosity of platform components without modifying individual deployment configurations.

For configuration details, see Custom Pod Annotations and Log Level.

Loading Savepoints from Custom Locations Through the UI​

Ververica Platform now supports loading savepoints from custom storage locations through the UI, in addition to the API-based method available in Ververica Platform 3.1.0. This completes the savepoint restoration workflow across all platform interfaces, making it straightforward to restore state from external sources such as savepoints taken from Ververica Platform 2.x deployments without requiring direct API calls.

For more information, see Loading Savepoints from Custom Locations.

CRD Rename for Ververica Platform 2.x and 3.x Co-installation​

Installations using Kubernetes Operator reconciliation encountered a conflict where the Ververica Platform 2.x and 3.x CRDs shared the same group, singular, plural, and shortNames, making co-existence on the same cluster impossible.

Ververica Platform 3.1.1 renames the custom resource definition from vvpdeployments.ververica.platform to vvp3deployments.v3.ververica.platform. This allows both versions to co-exist within the same Kubernetes cluster and enables migration between the two.

If you are upgrading from Ververica Platform 3.1.0 or earlier versions, additional migration steps are required. See the Upgrade section for details.

Bug Fixes​

API Token Page Flickering​

Fixed an issue where the API Token management page would flicker during background request polling, causing a disruptive visual experience when viewing or managing tokens.

Deployment Deletion Error​

Fixed an issue where deleting a deployment in Ververica Platform 3.1.0 returned a 500 Internal Server Error, preventing deployments from being removed through the UI or API.

Pod Template Spec Fields​

Fixed an issue where pod customization fields defined under jobManagerPodTemplate.spec and taskManagerPodTemplate.spec, including affinity, tolerations, nodeSelector, and volumes, were accepted by the API but silently dropped at runtime. Only metadata.labels and metadata.annotations were applied. All supported spec.* fields now correctly propagate to rendered JobManager and TaskManager pods.

Namespace Management Page​

Fixed an issue where the namespace management page did not display all namespaces accessible to the current user. Namespaces where the user had an assigned role appeared in the sidebar navigation but were missing from the admin namespace list.

Volume Quantity Parsing​

Fixed a NullPointerException that occurred when a volume definition included a standard Kubernetes Quantity string (for example, storage: 520Gi) in kubernetes.pods.volumeMounts or kubernetes.taskManagerPodTemplate. The deserializer only handled the Kubernetes-internal object form of a Quantity and did not recognize the standard YAML string form, causing deployments with ephemeral or persistent volume configurations to fail at deployment time.

YAML Resource Editor​

Fixed an edge case where certain field updates made through the YAML editor in the UI appeared to save successfully but were not persisted to the backing resource.

These fixes address vulnerabilities in OS-level packages within the Flink container image that Ververica Platform deploys.

Vulnerability Fixes (Ververica Platform Components)​

  • Removed fast-uri to address CVE-2026-6321, CVE-2026-6322
  • Removed libcrypto3, libssl3, openssl to address CVE-2026-2673, CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790
  • Removed libexpat to address CVE-2026-32776, CVE-2026-32777, CVE-2026-32778
  • Removed libpng to address CVE-2026-25646, CVE-2026-33416, CVE-2026-33636, CVE-2026-34757, CVE-2026-40930
  • Removed musl, musl-utils to address CVE-2026-40200, CVE-2026-6042
  • Removed org.apache.opennlp:opennlp-tools to address CVE-2026-40682, CVE-2026-42027, CVE-2026-42440
  • Removed org.apache.poi:poi-ooxml to address CVE-2025-31672
  • Removed zlib to address CVE-2026-22184, CVE-2026-27171
  • Updated @angular/core to 21.2.4 to address CVE-2026-27970, CVE-2026-32635
  • Updated ch.qos.logback:logback-core to 1.5.34 to address CVE-2026-1225
  • Updated follow-redirects to 1.16.0 to address GHSA-r4q5-vmmm-2653
  • Updated io.netty:netty-codec to 4.1.135.Final to address CVE-2026-42583
  • Updated io.netty:netty-codec-dns to 4.1.135.Final to address CVE-2026-42579
  • Updated io.netty:netty-codec-http to 4.1.135.Final to address CVE-2026-33870, CVE-2026-41417, CVE-2026-42580, CVE-2026-42581, CVE-2026-42584, CVE-2026-42585
  • Updated io.netty:netty-codec-http, io.netty:netty-codec-http2 to 4.1.135.Final to address CVE-2026-42587
  • Updated io.netty:netty-codec-http2 to 4.1.135.Final to address CVE-2026-33871
  • Updated io.netty:netty-handler-proxy to 4.1.135.Final to address CVE-2026-42578
  • Updated js-yaml to 3.14.2 to address CVE-2025-64718
  • Updated libcrypto3, libssl3 to 3.5.6-r0 to address CVE-2026-2673, CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390, CVE-2026-31789, CVE-2026-31790
  • Updated lodash to 4.18.1 to address CVE-2025-13465
  • Updated lodash, lodash-es to 4.18.1 to address CVE-2026-2950, CVE-2026-4800
  • Updated musl, musl-utils to 1.2.5-r23 to address CVE-2026-40200, CVE-2026-6042
  • Updated nginx to 1.30.2-r1 to address CVE-2026-9256
  • Updated org.apache.commons:commons-compress to 1.28.0 to address CVE-2023-42503, CVE-2024-25710, CVE-2024-26308
  • Updated org.apache.logging.log4j:log4j-core to 2.25.4 to address CVE-2025-68161, CVE-2026-34477, CVE-2026-34478, CVE-2026-34480
  • Updated org.apache.tomcat.embed:tomcat-embed-core to 10.1.55 to address CVE-2026-25854, CVE-2026-29129, CVE-2026-32990, CVE-2026-34483, CVE-2026-34487, CVE-2026-41284, CVE-2026-41293, CVE-2026-42498, CVE-2026-43512, CVE-2026-43513, CVE-2026-43514, CVE-2026-43515
  • Updated org.bouncycastle:bcpg-jdk18on to 1.84 to address CVE-2026-3505
  • Updated org.bouncycastle:bcpkix-jdk18on to 1.84 to address CVE-2026-5588
  • Updated org.bouncycastle:bcprov-jdk18on to 1.84 to address CVE-2026-0636, CVE-2026-5598
  • Updated org.pac4j:pac4j-core to 6.4.1 to address CVE-2026-40458
  • Updated org.postgresql:postgresql to 42.7.11 to address CVE-2026-42198
  • Updated org.springframework.boot:spring-boot to 3.5.15 to address CVE-2026-40973
  • Updated org.springframework.security:spring-security-core to 6.5.11 to address CVE-2026-22746, CVE-2026-22751
  • Updated org.springframework.security:spring-security-oauth2-jose to 6.5.11 to address CVE-2026-22748
  • Updated org.springframework:spring-webmvc to 6.2.19 to address CVE-2026-22741, CVE-2026-22745
  • Updated org.thymeleaf:thymeleaf, org.thymeleaf:thymeleaf-spring6 to 3.1.5.RELEASE to address CVE-2026-40477, CVE-2026-40478, CVE-2026-41901
  • Updated qs to 6.15.2 to address CVE-2026-8723
  • Updated tools.jackson.core:jackson-core to 3.1.1 to address CVE-2026-29062, GHSA-2m67-wjpj-xhg9, GHSA-72hv-8253-57qq
  • Updated ws to 8.21.0 to address CVE-2026-45736
  • Updated yaml to 2.8.3 to address CVE-2026-33532
  • Updated zlib to 1.3.2-r0 to address CVE-2026-22184, CVE-2026-27171

Upgrade​

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

helm upgrade --install <RELEASE_NAME> \
  oci://registry.ververica.cloud/platform-charts/ververica-platform \
  --version 3.1.1 \
  --namespace vvp-system \
  --values values.yaml

Ververica Platform 3.1.1 renames the operator CRD from vvpdeployments.ververica.platform to vvp3deployments.v3.ververica.platform. The API group also changes (ververica.platform → v3.ververica.platform), which fully separates it from the Ververica Platform 2.x CRD so the two no longer collide. As a result, existing custom resources change both their apiVersion and their owner-label key. Besides that the license-fingerprint secret is now Helm-managed.

Before running the upgrade, adopt the existing license-fingerprint secret into Helm — in 3.1.0 it is created by the platform, and the upgrade fails with an "invalid ownership metadata" error otherwise:

kubectl -n vvp-system annotate secret vvp-license-fingerprint \
  meta.helm.sh/release-name=ververica-platform \
  meta.helm.sh/release-namespace=vvp-system --overwrite
kubectl -n vvp-system label secret vvp-license-fingerprint \
  app.kubernetes.io/managed-by=Helm --overwrite

Then run the Helm upgrade shown above.

note

The following steps apply only if you use the Kubernetes Operator and have existing VvpDeployment custom resources.

  1. Back up your custom resources:

    kubectl get vvpdeployments.ververica.platform -A -o yaml > crs-backup.yaml

  2. Install the new CRD. Helm applies CRDs only on the first install, never on upgrade:

    kubectl apply -f charts/ververica-platform-crd/crds/vvp3deployments.yaml

  3. Re-create the resources under the new group. The backup cannot be applied as-is: rewrite each resource's apiVersion to v3.ververica.platform/v1, rename the ververica.platform/owner label to v3.ververica.platform/owner, drop server-managed metadata and status, then apply. The operator patches the existing deployments, so running jobs are not restarted.

    python3 - <<'PY'
    import yaml
    items = []
    for doc in yaml.safe_load_all(open('crs-backup.yaml')):
        if not doc: continue
        items += doc.get('items', [doc]) if doc.get('kind') == 'List' else [doc]
    out = []
    for it in items:
        if it.get('kind') != 'VvpDeployment': continue
        it['apiVersion'] = 'v3.ververica.platform/v1'
        m = it.setdefault('metadata', {})
        for k in ('resourceVersion','uid','creationTimestamp','generation','managedFields','finalizers','selfLink'):
            m.pop(k, None)
        (m.get('annotations') or {}).pop('kubectl.kubernetes.io/last-applied-configuration', None)
        labs = m.get('labels') or {}
        if 'ververica.platform/owner' in labs:
            labs['v3.ververica.platform/owner'] = labs.pop('ververica.platform/owner')
        it.pop('status', None)
        out.append(it)
    yaml.safe_dump_all(out, open('crs-migrated.yaml', 'w'))
    PY

    kubectl apply -f crs-migrated.yaml
    kubectl get vvp3deployments.v3.ververica.platform -A   # confirm all resources are present and healthy

  4. Remove the old CRD. Clear the leftover finalizers first, or it hangs in Terminating. This is cleanup only and does not affect any Ververica Platform 2.x installation:

    for cr in $(kubectl get vvpdeployments.ververica.platform -A \
          -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\n"}{end}'); do
      kubectl -n "${cr%/*}" patch vvpdeployment.ververica.platform "${cr#*/}" \
        --type=merge -p '{"metadata":{"finalizers":[]}}'
    done
    kubectl delete crd vvpdeployments.ververica.platform
note

If you are running Ververica Platform 2.15.x and have not yet migrated to Ververica Platform 3.x, upgrade directly to Ververica Platform 3.1.1 rather than 3.1.0, as the CRD naming conflict is resolved in this release.

On this page