Skip to content
Unified Defense StackUnified Defense Stack

UDS Core 1.13

UDS Core 1.13 publishes UDS CLI Next demo bundles alongside the legacy bundles and moves primary demo bundle CI coverage to the Next workflow. This release also expands K3s compatibility testing across Kubernetes 1.34 through 1.36, lets you disable HTTP 421 misdirected-request protection, and improves upgrade reliability.

Notable features

Section titled “Notable features”
  • UDS CLI Next demo bundles: UDS Core now publishes k3d-core-demo-next and k3d-core-slim-dev-next alongside their legacy counterparts. Primary CI workflows build, deploy, and test the Next bundles where possible, while the CLI compatibility matrix continues to validate legacy bundles during the transition. The standard Next bundle uses functional layer packages, reducing Core deployment times in CI by approximately 25 to 40 percent. Consuming the Next bundles requires UDS CLI v0.36.0 or newer with NextMode enabled (#2941).
  • Expanded Kubernetes compatibility testing: UDS Core now validates K3s 1.34, 1.35, and 1.36. A nightly matrix tests exact K3s 1.34 and 1.35 releases across the upstream, registry1, and unicorn flavors, while the default CI path validates K3s 1.36. This testing provides earlier visibility into compatibility issues but does not replace the UDS Core support policy. See Supported Kubernetes distributions (#2948).
  • Configurable misdirected-request protection: Set istio-controlplane.uds-global-istio-config.misdirectedRequest.enabled to false to disable the Envoy filter that rejects HTTP/2 requests when the :authority header does not match the TLS Server Name Indication (SNI). The filter remains enabled by default in 1.13, but UDS Core 2.0 will disable it by default. Set the value explicitly to true if you need to preserve the current behavior across that upgrade. Disabling the filter can improve compatibility with clients such as Safari that do not retry HTTP 421 responses, but removes protection against connection reuse across gateways with overlapping certificates (#2962).
  • Checkpoint restore ordering: Checkpoint creation now quiesces Keycloak, the Pepr watcher, Pepr admission, and ztunnel in dependency order. Restore starts those components in reverse order and waits for each rollout, preventing timeouts caused by suspending cluster infrastructure such as Istiod (#2944).
  • Shared egress reconciliation safety: The UDS Operator now verifies that stale shared egress resources still belong to an old generation before deleting them. This prevents cleanup from deleting newly updated resources during concurrent reconciliation (#2924).
  • Namespace metadata preservation: Keycloak, Authservice, CA bundle, and uptime initialization now create namespaces only when they do not exist. Existing namespaces retain metadata managed by Pepr, Istio, and other controllers (#2935).
  • Stable Gateway API Helm ownership: UDS Core now manages Gateway API resources through a stable local Helm chart instead of a generated chart name. Upgrades automatically migrate resources owned by the previous Zarf-generated release, reducing ownership conflicts across deployment tools (#2940).

Dependency updates

Section titled “Dependency updates”
PackagePreviousUpdated
Envoy Gatewayv1.8.3v1.9.1
Envoy Proxyv1.39.0v1.39.1
Falcosidekick2.34.12.35.0
Keycloak26.7.226.7.3
Loki3.7.63.7.7
Loki Helm chart18.7.618.12.1
k8s-sidecar2.10.12.11.2
Metrics Server Helm chart3.13.13.14.0
Vector0.57.00.58.0
Vector Helm chart0.57.00.58.0

Upgrade considerations

Section titled “Upgrade considerations”

UDS Identity Config 0.32.0

Section titled “UDS Identity Config 0.32.0”

The v1.13.1 patch updates UDS Identity Config to 0.32.0. This release adds the CNSS policy object identifier for SIPR tokens and includes plugin and dependency updates. The upstream release notes do not identify breaking changes or manual Keycloak realm steps.

Gateway API server-side apply conflicts

Section titled “Gateway API server-side apply conflicts”

UDS Core 1.13 moves Gateway API CRDs and the Gateway API safe-upgrades admission policy resources from the previous generated Helm release to the stable gateway-api-crds chart. Long-running clusters may fail this migration if they previously deployed those resources with UDS CLI versions before v0.30.0, when Helm used uds as its field manager. UDS CLI v0.30.0 and later use the zarf field manager by default.

Symptom: The gateway-api-crds deployment fails with server-side apply conflicts on Gateway API CRDs or safe-upgrades.gateway.networking.k8s.io admission resources.

Solution: Run the affected UDS CLI bundle deploy once with uds deploy uds-bundle-<name>-<arch>-<version>.tar.zst --force-conflicts, substituting your generated bundle name, architecture, and version. Remove the flag after the migration succeeds.

Section titled “Related documentation”
Cookie SettingsPrivacy Policy