Tetrate Service BridgeVersion: 1.12.x

Release Notes

Version 1.12.1

Added support for multiple hosts in the n2ac component for external Postgres datastore.
Credentials provided for the data store username and password will now be automatically URL-encoded and stored in the postgres-credentials secret within the Management Plane namespace. This change helps ensure compatibility with database drivers that require URL-encoded credentials (especially when using non-standard characters). If you are already supplying URL-encoded credentials, you must do one of the following to avoid double-encoding:
1. Update the secret to remove URL encoding, or
2. Set passwordEncoding to URL in the ManagementPlane CR, as shown below:
```
spec:
  dataStore:
    passwordEncoding: URL
```
No additional action is required if your credentials are not already URL-encoded.
Prevent Direct mode objects from being attached to Bridged mode Groups.
Added the FORCE_ALLOW_REUSE_OF_EDGE_CLUSTER_NAME environment variable to XCP Central to support edge clusters that retain the same name after a control plane cluster rebuild or re-installation.
- Previously, when an edge cluster was rebuilt, it received a new UID, causing Central to reject updates from the cluster. Enabling this flag allows Central to bypass the UID check and accept updates from the edge cluster.
- When enabled, Central will accept configuration updates from clusters that share the same name. However, this can potentially overwrite updates from the original cluster, which may not be the desired behavior. As a precaution, this feature is disabled by default.
Istio IsolationBoundary is now enabled by default.
Added Alpha support for Istio Ambient mode.
Add support for XCP managed selfSigned webhook certificates.
Add option to disable cert-manager installation by using tsbManaged internal certificate provider.
Add new API to list the config status related to a given FQDN. Available with tctl status --fqdn command.
Fixed the following CVEs: CVE-2025-22870, CVE-2025-30204, CVE-2024-21235, CVE-2024-55549, CVE-2025-24855, CVE-2025-27113, CVE-2025-1094, CVE-2024-12797, CVE-2025-27144.

Upgrade Notes

If you are running TSB version 1.10.x or below without the IsolationBoundary feature enabled, please be aware that it must be enabled as a pre-upgrade step before moving to TSB version 1.12.1. This involves performing a helm upgrade --install with an updated Control Plane CR that includes the IB configuration.
- Please refer to the Non-revisioned to revisioned upgrade doc for more details.
Starting from TSB version 1.9.x, if IsolationBoundary is enabled and the upgrade steps still reference dataplane component installation, those steps must be removed from the upgrade process. The use of dataplane component is not applicable when IsolationBoundary is enabled and may cause interference. You can use --exclude-dataplane command in tctl generate manifests to generate manifests without dataplane components.
During the Control Plane upgrade, TSB will automatically upgrade the Istio installation to the latest version if istio.tsbVersion field is not specified in the IsolationBoundary configuration.
If you have IsolationBoundary enabled in your Control Plane clusters and want to opt for an automatic Istio upgrade along with the Control Plane upgrade, ensure that the istio.tsbVersion field is left empty.
```
isolationBoundaries:
- name: global
  revisions:
  - name: default
    istio: {}
  - name: canary
    istio: {}
```
In some upgrade scenarios, the previous tsb-controlplane may not terminate fully. This can lead to a race condition where the ControlPlane CR gets defaulted with a tsbVersion, reverting to older behavior. If this happens during an in-place upgrade, manually remove the tsbVersion field from the ControlPlane CR. If manual intervention isn't possible, please contact Tetrate Support to discuss adding a post-upgrade step to your pipeline.
To improve reliability, TSB has introduced changes that require a one-time transient downtime during the upgrade. The downtime will last as long as it takes for all IstioD pods to complete their upgrade.

Avoiding Downtime
- If a transient downtime during the upgrade is not acceptable, you can avoid it by applying an overlay to the IstioD deployment before upgrading.
- This overlay should modify the DISCOVERY_REVISIONS environment variable to include all revisions within the same IsolationBoundary, as well as the boundary name itself, separated by commas.
- For example, if you have two revisions i.e default and canary under the global boundary, the overlay would look like this:
```
isolationBoundaries:
- name: global
  revisions:
    - name: default
      istio:
        kubeSpec:
          deployment:
            env:
              - name: DISCOVERY_REVISIONS
                value: default,canary,global
    - name: canary
      istio:
        kubeSpec:
          deployment:
            env:
              - name: DISCOVERY_REVISIONS
                value: default,canary,global
```

UI

Fixed the backward compatibility issue of status_code and percentile metrics in the UI.
Fixed an issue where the paths and methods of LocalAuthZ could not be edited in the UI.
Fixed a bug where the service is not refreshed by the Refresh Button in the UI.
Fixed an issue where the Segmentation Toggle was wrongly displayed in the TIS+ UI.
Add support for Install Gateway.
Add Hostname and External Addresses options to the search functionality in the Workspace Propagation view.

Outstanding CVEs

At the time of shipping, there are no Critical and High vulnerabilities flagged. The following CVEs (medium/low) have been identified as being present in some images by our security tools. They have been evaluated by Tetrate Product Security and are not exploitable in TSB installations. Where applicable, this was ascertained by using static code analysis tools.

CVE-2025-1376 - No fix available.
CVE-2024-10041 - No fix available.
CVE-2025-1390 - No fix available.
CVE-2024-8176 - No fix available.
CVE-2024-12243 - No fix available.
CVE-2025-1371 - No fix available.
CVE-2024-10963 - No fix available.
CVE-2024-12133 - No fix available.
CVE-2025-24528 - No fix available.
CVE-2024-52005 - No fix available.
CVE-2024-45341 - No fix available.
CVE-2025-23022 - No fix available.
CVE-2025-1372 - No fix available.
CVE-2024-26462 - No fix available.
CVE-2025-27516 - No fix available.
CVE-2024-0406 - No fix available.
CVE-2024-2236 - No fix available.
CVE-2025-0167 - No fix available.
CVE-2024-41996 - No fix available.
CVE-2023-29383 - No fix available.
CVE-2024-9143 - No fix available.
CVE-2023-7008 - No fix available.
CVE-2024-22365 - No fix available.

Version 1.12.0

Added the K8S_CACHE_SYNC_TIMEOUT environment variable to the TSB operators to configure the amount to wait for the Kubernetes cache synchronization when the operator pods start. The default value is 2 minutes, but in large environments with lots of configuration objects this may need to be increased.

The rate limit filters were not installed on the listeners on port 15443, used for multi-cluster traffic. Starting in 1.12, rate limits will also be enforced for traffic going through that port. This could be a breaking change for some applications, and can be turned off by applying the following overlay in the ControlPlane resource in the application clusters

spec:
  components:
    xcp:
      kubeSpec:
        overlays:
        - apiVersion: install.xcp.tetrate.io/v1alpha1
          kind: EdgeXcp
          name: edge-xcp
          patches:
          - path: spec.components.edgeServer.kubeSpec.deployment.env[-1]
            value:
              name: DISABLE_RATE_LIMIT_PORT_15443
              value: "true"

The built-in roles have been updated to include permissions to manage configuration profiles.
Segmentation Membership objects now accept the FQN of Cluster objects in the fqnSelector field to create cluster-based policies.
Traffic settings in configuration profiles are now enforced exclusively through the new inbound and outbound fields, available in both the defaults and mandates sections of a profile.

Upgrade notes

OAP Upgrade

OAP adds more attributes to metrics for querying and analysis. When upgrading, OAP can assure the compatibility between management plane and control plane. But within a cluster, OAP instances route and aggregate metrics from each other. So rolling an update in a cluster can cause replicas to temporarily stop aggregating metrics while they are running lower version and master version at the same time. This could output some predictable errors in the logs, like:

2025-02-20 10:18:21,922 - org.apache.skywalking.oap.server.core.remote.RemoteServiceHandler -44362 [grpc-default-executor-1] ERROR [] - Index 2 out of bounds for length 2

The OAP instances will recover aggregating metrics and stop printing the above logs when the upgrade is completed. Although this case is normal and predictable, if you want to avoid this, you can upgrade OAP by the following steps:

Before upgrading, scale down the OAP replicas to 0.
Recover OAP replicas after the deployment is upgraded.

Version 1.12.1​

Upgrade Notes​

Avoiding Downtime​

UI​

Outstanding CVEs​

Version 1.12.0​

Upgrade notes​

OAP Upgrade​