## What this PR does
Moves the pinned Alpine runtime bases of the first-party images forward
to `alpine:3.24`, clearing the published `musl` / `zlib` advisories
carried by the stale layers.
| image | base |
| --- | --- |
| mariadb-backup | 3.20 → 3.24 |
| cozystack-operator | 3.22 → 3.24 |
| platform-migrations | 3.22 → 3.24 |
| grafana-dashboards | 3.22 → 3.24 |
| kubeovn-webhook | 3.21.3 → 3.24 |
| redis-operator | latest → 3.24 |
Each runtime `apk` set was verified to resolve on `alpine:3.24`. These
images rebuild on the release asset pipeline, which re-pins the digests
in `values.yaml` on the next build — matching how the rest of the ~30
first-party images pick up the shared base (the issue's "rebuild and run
the standard test pipeline").
**Scope notes:**
- The build-only `alpine AS source` stages (keycloak-operator,
objectstorage-controller) are left as-is: their final images are
distroless, so no Alpine layer ships.
- The s3manager base is owned by the separate bucket bump (#2887), and
kilo's base moves in its own image rebuild (#2898).
- **Side effect for platform-migrations**: its `kubectl` / `helm` come
from the Alpine repo, so the base bump moves them `1.33 → 1.36` and
`3.18 → 3.19`. Both are current upstream stable and in skew with the
modern control plane for the migration scripts' operations (apply / get
/ label / helm release ops).
Closes#2902
### Release note
```release-note
chore(images): refresh first-party Alpine runtime bases to 3.24 to clear the musl/zlib advisories
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated Alpine Linux base images across multiple application
containers to version 3.24 (including backup utilities,
platform/operator components, monitoring dashboards, and
networking/webhook components) to improve security and build
consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Re-vendors the CoreDNS Helm chart from `1.43.2` to `1.46.0` (chart
`appVersion` `1.12.3` → `1.13.1`) and pins the `make update` target to
`--version 1.46.0` so re-vendoring is reproducible (it was previously
tracking upstream `latest` silently).
The running CoreDNS **image is deliberately kept** at
`registry.k8s.io/coredns/coredns:v1.12.4`. It is pinned to the 1.12 line
that matches the Kubernetes-bundled kube-dns replacement, and v1.12.4 is
the latest patch of that line (itself a security release). The
cozystack-side `values.yaml` pins `coredns.image.tag: v1.12.4`, so the
chart's `appVersion` bump never reaches the deployed container — the
rendered Deployment still uses `v1.12.4`. The kube-dns overrides
(`k8sAppLabelOverride`, `service.name`, `serviceAccount.name`) stay
valid.
The new chart template logic (`dnsConfig`/`dnsPolicy`, ServiceMonitor
`scrapeTimeout`/`scheme`/`honorLabels`/`tlsConfig`/relabelings,
multicluster RBAC, `customAnnotations`, `automountServiceAccountToken`)
is inert under the cozystack values — none of those keys are set, so
every new conditional is skipped and the bump is behavior-neutral for
the pinned configuration.
This references #2899 but does **not** close it: that ticket asks to
advance the CoreDNS *image* for CVE remediation, which conflicts with
the kube-dns version alignment. Whether to move the bundled CoreDNS line
forward (and thus the image) is a platform-level call, left open on the
issue.
### Release note
```release-note
chore(coredns): refresh vendored CoreDNS chart to 1.46.0 (image held at v1.12.4 for kube-dns alignment)
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added DNS policy and custom DNS configuration options for deployments
* Introduced pod labels support for custom pod labeling
* Expanded Prometheus monitoring with scrape timeout, TLS configuration,
and relabeling options
* Added multicluster RBAC support capability
* **Chores**
* Updated CoreDNS to version 1.13.1
* Bumped Helm chart version to 1.46.0
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Re-vendors the HAMi vGPU chart from 2.8.1 to 2.9.0, moving the
device-plugin and scheduler-extender images to `projecthami/hami:v2.9.0`
and picking up the published security fixes.
**Vendoring approach changed for 2.9.0.** Upstream now gates the
scheduler and device-plugin templates on `.Values.dra.enabled` and
`.Values.podSecurityPolicy.enabled` across ~27 files, so the previous
approach (strip the dra/PSP values and remove the conditionals by hand)
would nil-pointer at render time. Instead the `dra:` and
`podSecurityPolicy:` blocks are KEPT at their upstream default
(`enabled: false`), which cleanly disables both paths; only the unused
`hami-dra` subchart and its values block are removed. The Makefile
vendoring notes are updated to document this.
Replays the `indent`→`nindent` patch on the custom Service labels block
— now extended to **both** Services that carry the upstream defect: the
device-plugin monitor Service and the scheduler Service (the latter was
previously unpatched and would emit invalid YAML if
`scheduler.service.labels` were set).
Adds helm-unittest coverage (the package shipped none): pins the
device-plugin image and guards the nindent patch on both Services. `helm
unittest` 3/3 pass.
Note: the vendored `charts/hami/README.md` still documents the old
`global.imageTag` default — that is an upstream autogenerated-doc bug
carried in by `make update`; per the vendoring policy it is left
untouched (the operative `values.yaml` default is correctly `v2.9.0`).
Closes#2897
### Release note
```release-note
chore(hami): bump HAMi to 2.9.0
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added DRA (Dynamic Resource Allocation) support with feature flag
* Added Vastai device support
* Added Prometheus ServiceMonitor templates for metrics collection
* Enhanced scheduler with Kubernetes 1.22+ native API support
* **Improvements**
* Upgraded HAMi to v2.9.0
* Expanded Ascend device configuration options
* Added legacy metrics compatibility mode
* Improved PodSecurityPolicy support
* Enhanced service selector labels for better traffic routing
* **Tests**
* Added chart rendering tests for version verification and label
validation
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Re-vendors the FoundationDB Kubernetes operator chart from v2.13.0 to
v2.30.0 (chart 0.2.0 → 0.3.0), 17 minor releases forward, picking up the
published security fixes the issue enumerates. The operator +
init-monitor images advance to the current upstream tags that carry the
patched base packages.
The vendored tree is byte-identical to a fresh upstream `v2.30.0` clone
(templates + values + the three CRDs copied from `config/crd/bases/`).
The CRD changes are **additive only** — new fields, no property removals
(only the controller-gen / `foundationdb.org/release` version
annotations change) — so the `apps/foundationdb` FDB CR stays valid
against the new operator. cozystack overrides (`globalMode`,
`nodeReadClusterRole`) remain valid and consumed by the v2.30.0
templates. The one removed CLI flag (`genericclioption`) is not used by
cozystack; the chart's RBAC role binding is now unconditional
(previously globalMode-gated) — a no-op for cozystack, which sets
`globalMode=true`.
Adds helm-unittest coverage (the package shipped none): pins the
operator image.
Verified: `helm template` renders the operator at `v2.30.0`; `helm
unittest` 1/1 pass.
Closes#2879
### Release note
```release-note
chore(foundationdb-operator): bump fdb-operator to v2.30.0
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for custom environment variables plus additional pod
volumes and mounts for the operator.
* Expanded FoundationDB backup/cluster/restore CRD capabilities (new
backup modes, deletion policies, workload references, and pod template
options).
* **Bug Fixes**
* Adjusted RBAC service account binding behavior to use the release
namespace consistently.
* **Tests**
* Added image pin and global-mode rendering checks for operator
deployment.
* **Chores**
* Upgraded the FoundationDB operator Helm chart/app version and image to
v2.30.0; added a Helm unittest `test` target.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Re-vendors the openbao-helm chart from 0.25.3 to 0.25.7 (appVersion
v2.5.0 → v2.5.1), the latest in the `^0.25` line the Makefile pins. The
vendored tree is byte-identical to a fresh upstream pull; cozystack
overrides (`injector.enabled: false`, `csi.enabled: false`) are
untouched and still render nothing, so the changed runtime surface is
the openbao server StatefulSet image.
**Security scope (honest accounting):** v2.5.1 fixes two OpenBao CVEs —
including the critical **CVE-2025-68121** (Go stdlib TLS, CVSS 10.0, via
a Go 1.25.7 rebuild) and **CVE-2026-24051** (otel/sdk). The issue also
lists `github.com/jackc/pgx/v5` — that is **not** addressed: pgx is
unchanged in v2.5.1 upstream, so it can't be closed by an in-`^0.25`
bump. `libcap2`/`libexpat` are base-image packages picked up
incidentally by the rebuild (not verified here). Widening past 0.25.x to
0.28.x (app v2.5.5) would need a CHART_VERSION constraint change plus a
0.26/0.27/0.28 changelog review and is intentionally left out.
Adds helm-unittest coverage (the package shipped none): pins the server
image and the injector/CSI-disabled invariants. `helm unittest` 3/3
pass.
Closes#2895
### Release note
```release-note
chore(openbao): bump openbao chart to 0.25.7 (app v2.5.1, fixes critical CVE-2025-68121)
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for configuring headless service annotations (including
HA standby headless service).
* Enhanced the Grafana dashboard with consistent dynamic job filtering
across Prometheus queries.
* **Updates**
* Upgraded Helm chart to **0.25.7** (OpenBao app **v2.5.1**).
* Updated snapshot agent image tag to **0.3.0**.
* **Tests**
* Added Helm unit test coverage via a `helm unittest` Makefile target
and new chart rendering invariants.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Part of #2814. Part of #2811.
This is the foundational ("keystone") piece of WS3: a canonical,
reusable trust-anchor object that lets a tenant obtain `ca.crt` to
verify a per-app TLS endpoint **without** read access to any object that
also carries a private key. It unblocks the per-app TLS series (WS4/WS5)
by giving every chart one agreed, key-free delivery shape instead of
each chart inventing its own.
### The problem (verified against current `main`)
Per-app TLS issues a per-release, self-signed CA. The only objects that
hold `ca.crt` today also hold private keys:
- the cert-manager CA Secret `<release>-ca` carries the CA private key
(`tls.key`) — full trust-chain compromise if leaked
(`packages/apps/nats/templates/certmanager.yaml`, the `isCA`
Certificate);
- the cert-manager leaf Secret `<release>-tls` carries the server
private key (`tls.key`) plus `ca.crt` (same file, the leaf Certificate);
- CNPG surfaces `ca.crt` only inside its user-credentials Secret
(`packages/apps/postgres/templates/db.yaml`, the operator-managed TLS
block).
So any RBAC path that hands a tenant `ca.crt` by granting read on one of
those Secrets also hands over a private key. On `main` today the
cert-manager apps grant tenants no access to those Secrets at all, so a
tenant currently cannot obtain `ca.crt` to verify the server — the gap
this object closes safely.
### Design decision: key-free Opaque object delivered through
`tenantsecrets`, not trust-manager
I evaluated the two candidate delivery mechanisms.
**Rejected — trust-manager.** A trust-manager `Bundle` reads its sources
only from trust-manager's single configured "trust namespace"; its
`namespaceSelector` governs only where the bundle is *distributed to*,
not where it is *sourced from*. A per-release self-signed CA lives in
the tenant namespace, so trust-manager cannot use it as a source, and
projecting one shared CA to all tenants would defeat per-release
isolation. I re-verified this against current upstream docs
(cert-manager.io trust-manager) and the open per-namespace-trust-bundle
request (cert-manager/trust-manager#131, which is target-side only). The
prior analysis still holds.
**Chosen — a `ca.crt`-only Opaque Secret surfaced through the existing
tenant-secret API.** This generalizes the reference pattern from the
redis work (#2729), where the operator publishes a CA-only Opaque Secret
and RBAC is scoped to it instead of to the CA-private-key Secret. The
new `cozy-lib.tls.caCertSecret` helper renders that object once,
identically, for every chart:
- `type: Opaque`, a single `ca.crt` data key, no `tls.key`/`tls.crt`;
- label `internal.cozystack.io/tenantresource: "true"`;
- fails closed on empty input and refuses any PEM that contains private
key material.
### How the RBAC wiring works (no new roles needed)
The label is the entire mechanism, and it routes through RBAC that
already exists:
- `pkg/registry/core/tenantsecret/rest.go` surfaces, under the virtual
resource `core.cozystack.io/tenantsecrets`, exactly the namespace
Secrets bearing `internal.cozystack.io/tenantresource=true`
(`buildTenantSelector`, lines 199-213; label constants
`pkg/apis/core/v1alpha1/tenantresource_types.go:3-4`; full `Data` copied
through by `secretToTenant`, lines 84-103).
- `packages/system/cozystack-basics/templates/clusterroles.yaml` grants
`get/list/watch` on `core.cozystack.io/tenantsecrets` to tenant
ServiceAccounts via `cozy:tenant:base` (lines 44-47) and to
`use`/`admin`/`super-admin` subjects via `cozy:tenant:use:base` (lines
179-180). None of this touches raw core `secrets`, so attaching the
label to a key-free object exposes the trust anchor and nothing else.
- `internal/backupcontroller/credentials_projector.go:128-133` relies on
the same rule in reverse — it deliberately *omits* the label so its
key-bearing projection is not promoted to a `TenantSecret`. This helper
is the positive counterpart: a key-free object that is safe to promote.
`view` deliberately does not receive the trust anchor through this path:
`cozy:tenant:view:base` grants only `core.cozystack.io/options` (lines
120-126), and `tenantsecrets` also includes credential Secrets, so
granting it to a read-only role would leak passwords. The trust anchor
reaches `use` and above plus tenant ServiceAccounts — the same access
level at which connection credentials are already surfaced (the
per-release dashboard Role binds at `use`, e.g.
`packages/apps/postgres/templates/dashboard-resourcemap.yaml` via
`cozy-lib.rbac.subjectsForTenantAndAccessLevel`). A chart that must show
`ca.crt` at `view` level in the dashboard can additionally name the
key-free Secret in its own per-release Role; that is a per-app detail,
not a base-role change.
### Why a library helper and not a controller here
Populating `ca.crt` stays the responsibility of whatever owns the PKI —
the app operator (as the redis fork does) or a cert-manager chain
resolved at the chart level. The helper is intentionally pure and
value-driven so it renders deterministically and is the single shape
every per-app PR converges on. A shared key-stripping projection
controller is a reasonable future generalization but is out of scope for
this foundational object.
### Convergence plan for the per-app TLS series (follow-up, not this PR)
I did not modify any of the open per-app branches. Each should adopt the
canonical object as follows:
- redis #2729 — already publishes an operator-side CA-only Opaque Secret
and already drops the grant on the CA-private-key Secret; converging
means emitting it through the helper / carrying the `tenantresource`
label so delivery matches the rest of the catalog.
- nats, qdrant (merged, cert-manager) — emit the canonical object via
the helper and withhold `<release>-ca` / `<release>-tls` from tenants.
- mariadb #2680, opensearch #2682, rabbitmq #2683, mongodb #2692 — same:
emit the canonical object, never grant a Secret that contains `tls.key`.
### Tests
`helm-unittest` in the cozy-lib test chart (`make -C
packages/tests/cozy-lib-tests test`) covers: the rendered object is
`Opaque` with `ca.crt` and no `tls.key`/`tls.crt`; the `tenantresource`
label is present; caller labels/annotations merge while the security
label always wins; the helper fails closed on empty `caCert`; and it
refuses a PEM that carries private key material.
### Release note
```release-note
NONE
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Added a Helm helper to generate CA-only Kubernetes TLS trust-anchor
secrets, including input validation (rejects private key material,
requires a properly formatted certificate, and ensures required
metadata).
* **Tests**
* Introduced a dedicated test suite covering successful rendering,
metadata and content assertions, tenant label enforcement,
label/annotation merging, and detailed failure cases for invalid inputs
and incorrect arguments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
On the default ingress-nginx path (`gateway.enabled=false`) every
published hostname still minted its own per-host ACME certificate via
ingress-shim, even with a DNS-01 solver configured. That hits the Let's
Encrypt rate limit (50 certs per registered domain per week) once a
deployment exceeds ~50 endpoints. The Gateway API path already issues a
single per-apex wildcard in DNS-01 mode; this brings the ingress-nginx
path to parity. It implements the remaining ingress-nginx gap that #2400
was narrowed to in its triage comment (DNS-01 is already multi-provider,
and the Gateway path already issues wildcards).
The new `publishing.certificates.wildcard` toggle is opt-in and OFF by
default. When set to `true` with `solver=dns01` and no operator-provided
wildcard Secret, the platform issues one shared wildcard `Certificate`
for `<root-host>` + `*.<root-host>` and serves the resulting Secret as
the publishing controller's `--default-ssl-certificate`. The system
service Ingresses (dashboard, grafana, keycloak, harbor, …) then stop
requesting a per-host cert.
How it works:
- `core/platform` `apps.yaml` computes the effective wildcard Secret
name and a new `_cluster.wildcard-issue` signal. An operator-provided
`wildcardSecretName` (the BYO path) always wins and never triggers
issuance; HTTP-01 cannot issue wildcards; and when Gateway API is
enabled the TenantGateway controller issues the wildcard instead — so
all three are excluded from auto-issuance.
- `extra/ingress` renders the wildcard `Certificate` only on the
publishing controller (`Release.Namespace == expose-ingress`), because
the Secret must be same-namespace for ingress-nginx to read it. The
Certificate references the DNS-01 `ClusterIssuer` that
`cert-manager-issuers` already renders in `dns01` mode, so no per-tenant
Issuer is minted.
This reuses the existing wildcard-secret consumption path, so no
per-service Ingress template changes were needed — only the issuance
side is new.
Why opt-in (default off): the chosen wildcard Secret name rides the
`_cluster` channel, which every child tenant inherits verbatim, so this
is not root-tenant scoped. A single-label wildcard `*.<root-host>`
covers `<service>.<root-host>` but not a custom service host outside it
(a keycloak `ingress.host`, harbor `host`, or grafana `host` pointed at
another domain) nor a child tenant's nested host
(`<service>.<tenant>.<root-host>`). Enabling issuance makes every such
service drop its per-host ACME cert and fall back to the default
certificate, which does not cover it. Leaving it off by default means a
dns01 cluster is never silently switched on upgrade; an operator who
enables it accepts the same coverage responsibility as the
operator-provided wildcard path, which propagates identically. The
tradeoff is pinned by contract tests (keycloak custom host, bucket
nested child-tenant host). Per-tenant wildcards remain on the Gateway
path and are tracked separately.
Docs: cozystack/website#588Closes#2400. Part of #2811.
### Screenshots
N/A — no UI changes.
### Release note
```release-note
feat(platform): add opt-in shared wildcard certificate issuance on the default ingress-nginx path via publishing.certificates.wildcard (default false). When enabled with a DNS-01 solver, the platform issues one *.<root-host> wildcard for system services instead of a per-host ACME certificate, avoiding Let's Encrypt rate limits at scale.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added automatic wildcard certificate issuance support for DNS-01 ACME
solver.
* New `certificates.wildcard` configuration option to enable shared
wildcard TLS certificates.
* Ingress rules now properly utilize wildcard certificates when enabled.
* **Tests**
* Added comprehensive test suites validating wildcard certificate
generation and ingress integration across multiple scenarios.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Bumps the nats chart from 1.3.13 to 1.3.16 (app 2.11.8 → 2.11.10), the
latest patch in the 1.3 line, picking up the published security fixes
the issue enumerates (nats-server 2.11.10 bumps `golang.org/x/crypto` to
v0.42.0 and the Go toolchain to 1.24.7) plus upstream bug fixes
(route-reconnect storms, stream interest loss when lowering
max-connections, JetStream meta performance).
Pins the `update` target to `--version 1.3.16` so `make update` stays on
the 1.3 line instead of floating to the 2.x chart restructure. The
cozystack overrides (PVC retention policy, cluster routeURLs domain,
prometheus exporter PodMonitor) stay valid.
Adds helm-unittest coverage (the package shipped none): pins the server
image, the PVC retention policy, and the PodMonitor invariant. `helm
unittest` 3/3 pass.
Verified: `helm template` renders `nats:2.11.10-alpine`, the retention
policy, and the PodMonitor; vendored tree is byte-identical to a fresh
upstream pull.
Closes#2890
### Release note
```release-note
chore(nats): bump nats to 1.3.16 (app 2.11.10)
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* Added configurable Kubernetes `resources` (requests/limits) for the
NATS container and nats-box.
* **Chores**
* Updated NATS image to `2.11.10-alpine`.
* Updated config reloader image to `0.20.1`.
* Updated nats-box image to `0.19.2`.
* Updated the Helm chart to `1.3.16` (NATS appVersion to `2.11.10`).
* **Tests**
* Added automated Helm chart validation tests, including stricter
rendering checks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Bumps the vertical-pod-autoscaler chart from 10.0.0 to 11.1.1 (app 1.3.0
→ 1.5.0, latest upstream), moving the VPA components
(admission-controller, recommender, updater) to
`registry.k8s.io/autoscaling/vpa-*:1.5.1` and picking up the published
security fixes the issue enumerates.
The chart-major bump keeps every cozystack override valid: the
recommender's prometheus storage config (`storage=prometheus`,
`prometheus-address`, container labels), `crds.enabled: false`, and the
updater/admissionController resource blocks.
Two Bitnami-adjacent details, both correctly neutralized:
- Upstream 11.0 switched the bundled CRD-install Job image to
`bitnamilegacy/kubectl`. cozystack disables that Job (`crds.enabled:
false`) and overrides `crds.image` to `docker.io/alpine/k8s`, so no
Bitnami image is ever pulled — verified by render.
- The `common` library subchart dependency moved off the sunset Bitnami
repo (`charts.bitnami.com` → `oci://ghcr.io/cowboysysop/charts`), a free
supply-chain improvement.
VPA 1.5 deprecations (humanized memory flag, UpdateMode `Auto`) are not
used by cozystack.
Adds helm-unittest coverage (the package shipped none): pins the
recommender prometheus args, the non-Bitnami `registry.k8s.io` image,
and the `crds.enabled=false` → no CRD-install Job invariant. `helm
unittest` 3/3 pass.
Closes#2882
### Release note
```release-note
chore(vertical-pod-autoscaler): bump VPA to 11.1.1 (app 1.5.0)
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for `InPlaceOrRecreate` pod update mode.
* Improved OCI-based Helm install/upgrade documentation and examples.
* **Improvements**
* Updated chart/component versions (including VPA components to 1.5.x
and chart to 11.1.1).
* Hardened security defaults (seccomp RuntimeDefault and container
hardening) and added image integrity checks during upgrades.
* Expanded RBAC permissions for admission controller and event/workload
handling.
* **Chores**
* Updated the shared Helm library version and refreshed chart
tests/invariants.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Bumps velero from 11.0.0 to 12.0.3 (appVersion 1.17.0 → 1.18.1, latest
upstream), picking up the published security fixes the issue enumerates
across the velero server and its backup plugins.
- Re-vendors the chart via `make update` (now pinned to `--version
12.0.3` for reproducible re-vendoring). The 12.0 major bump's
values-schema changes are backward-compatible (two required fields
relaxed, one optional key added), so all cozystack overrides
(`upgradeCRDs`, `initContainers`, `configuration.*`, `deployNodeAgent`)
stay valid.
- Moves the backup-plugin initContainers to their velero-1.18-aligned
releases: `velero-plugin-for-aws` v1.12.1 → v1.14.1 (the release that
bumps to velero 1.18.1; also corrects a pre-existing plugin/server skew)
and `kubevirt-velero-plugin` v0.8.0 → v0.9.0.
- Adds helm-unittest coverage (the package shipped none): pins the
server + plugin image tags and the `upgradeCRDs: false` → no
upgrade-crds Job invariant, which has silently regressed before.
The 1.18 "PVC selected-node" deprecation needs no action (velero handles
it transparently); CRD changes are additive.
Verified: `helm template` renders all three images; `helm unittest` 3/3
pass (mutation-checked).
**Upgrade note:** Helm v3 does not update CRDs on `helm upgrade`
(upgradeCRDs is disabled). On existing clusters the 1.18 CRDs must be
applied manually (`kubectl apply --filename
packages/system/velero/charts/velero/crds/`).
Closes#2886
### Release note
```release-note
chore(velero): bump velero to 12.0.3 (app 1.18.1) and backup plugins to velero-1.18-compatible releases
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added Backup status queue tracking (`queuePosition`) plus new `phase`
states.
* Added `caCertRef` Secret reference for BackupStorageLocation (with
`caCert` marked deprecated).
* Added incremental-bytes reporting (DataUpload, PodVolumeBackup) and
`snapshotSize` for PodVolumeRestore.
* Added `backupSyncPeriod` configuration and `nodeAgent.disableHostPath`
option.
* **Upgrades**
* Updated Velero to app 1.18.1 / chart 12.0.3, including plugin image
tag bumps and updated kubectl image defaults.
* Added chart/app version labels across key resources.
* **Operational Improvements**
* Improved CRD cleanup/upgrade job execution and tuned the
“VeleroNoNewBackup” alert.
* **Tests**
* Added a `test` target (runs `helm unittest`) and expanded chart
rendering invariants checks.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Bumps the Percona Operator for MongoDB stack from 1.21.x to 1.22.0
(latest upstream release), picking up the published security fixes in
the operator image that the issue enumerates.
Two coupled changes:
- `system/mongodb-operator`: re-vendors the upstream psmdb-operator
chart 1.21.2 → 1.22.0 via `make update` (operator image →
`percona/percona-server-mongodb-operator:1.22.0`). The vendored tree is
byte-for-byte identical to a fresh upstream pull.
- `apps/mongodb`: bumps the managed CR `spec.crVersion` 1.21.1 → 1.22.0
so the platform tracks the deployed operator instead of running at the
N-1 skew, plus the matching helm-unittest assertion.
The 1.22.0 CRD diff is additive (native MinIO backup storage, storage
scaling, `hookScript`, `PBMReady` condition, new `metrics.k8s.io` RBAC
that activates under our `watchAllNamespaces: true`). The only schema
removal — the restore-spec `replset` string, renamed upstream to
`replsetRemapping` — is unused by the cozystack mongodb app (restore
template uses `clusterName`/`pitr`/`backupSource` only). Deprecations
(PSMDB 6.0, PMM2, `enableVolumeExpansion`) stay backward-compatible. The
PBM (`2.11.0`) and PMM (`2.44.1`, disabled by default) sidecars stay
compatible with 1.22.0 and are out of scope here.
Verified: `helm unittest packages/apps/mongodb` 94/94 pass; `helm
template` renders the operator with the new image.
**Upgrade note:** Helm v3 does not update CRDs on `helm upgrade`. On
existing clusters the 1.22.0 CRD must be applied manually (`kubectl
apply --server-side -f .../crds/crd.yaml`); the operator pod itself runs
fine against the older CRD until then.
Closes#2888
### Release note
```release-note
chore(mongodb): bump psmdb-operator to 1.22.0 and managed CR to crVersion 1.22.0
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **New Features**
* MongoDB Operator upgraded to version 1.22.0 with enhanced custom
resource definitions supporting backup storage configuration, hook
scripts, and storage autoscaling capabilities
* Added configurable namespace override for flexible operator deployment
* Extended RBAC permissions for metrics collection
* **Chores**
* Kubernetes minimum version requirement updated to 1.32+
* Helm chart version bumped to 1.22.0
* **Documentation**
* Expanded CRD upgrade and installation guidance with multiple upgrade
strategies
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Refreshes every supported Kubernetes minor in the `apps/kubernetes`
version map (`files/versions.yaml`) to its latest upstream patch,
picking up the published Go-stdlib / `x/net` fixes in the control-plane
component images:
| minor | from | to |
| --- | --- | --- |
| v1.35 | v1.35.1 | v1.35.6 |
| v1.34 | v1.34.4 | v1.34.9 |
| v1.33 | v1.33.8 | v1.33.13 |
| v1.32 | v1.32.12 | v1.32.13 |
`v1.31.14` and `v1.30.14` already track their latest patch. The
major/minor enum is unchanged, so `make generate` is a no-op (the values
schema, CRD and README are untouched). helm-unittest passes (129/129).
### Scope notes
- **Version range is intentionally held at v1.30-v1.35 and does NOT
advance to v1.36.** KubeVirt 1.8.2 rejects the kubelet checksum on
Kubernetes 1.36 (int32 CRD validation), leaving tenant VMIs stuck
`Scheduled` (tracked in #2769). The kamaji bump to `26.6.4-edge` raises
`KubeadmVersion` to `v1.36.0`, so `hack/update-versions.sh` would
otherwise pull v1.36 into this map — that expansion is deferred until
the KubeVirt regression is fixed.
- `hack/update-versions.sh` also caps the top minor at the exact
`KubeadmVersion` (`v1.35.0`), which would *downgrade* the current
`v1.35.1`. `v1.35` is set to the latest patch (`v1.35.6`) by hand
instead, matching the existing practice of running a patch above the
kubeadm tool version.
- The OS-package advisories from the scan (`libexpat`, `libpython3.13`,
`git`, `python3`, `perl`, …) live in the `ubuntu-container-disk` worker
images, built via `guestfish` from the floating `ubuntu noble/current`
base. Those clear when the release pipeline rebuilds them on the current
cloud image — the base is not digest-pinned, so no source change is
needed for them here.
Refs #2876
### Release note
```release-note
chore(kubernetes): refresh managed Kubernetes versions to latest patches (v1.35.6, v1.34.9, v1.33.13, v1.32.13)
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated Kubernetes version support for v1.35, v1.34, v1.33, and v1.32
with the latest patch releases.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Refreshes the `core/talos` asset/profile layer onto current upstream to
clear the published advisories the scanner flagged in the stale pinned
images (`libcrypto3` plus the Go-module advisories compiled into the
installer).
- **profiles**: regenerated by `hack/gen-profiles.sh v1.13.5`, moving
the base installer and every system extension to the v1.13.5 line —
installer `v1.13.0` → `v1.13.5`; `amdgpu`/`i915`/`drbd`/`zfs` to their
`-v1.13.5` builds; `amd-ucode` and the firmware blobs to the
`20260519`/`20260512` snapshots. The extension digests come verbatim
from the official `ghcr.io/siderolabs/extensions:v1.13.5`
`image-digests` manifest. v1.13.5 rebuilds the installer on the Go
1.26.4 toolchain and current runtime (kernel, containerd, runc,
OpenSSL).
- **matchbox**: base image `quay.io/poseidon/matchbox` `v0.10.0` →
`v0.11.0`, clearing the `libcrypto3` advisories in the matchbox runtime.
`v1.13.5` is the latest stable Talos release (no `v1.14` line yet).
`cozy-talos` ships no runtime templates — it drives the node-image /
installer / matchbox asset builds. The Talos installer and matchbox
images are rebuilt from these sources by the release asset pipeline (the
privileged imager build), which also re-pins the generated
`matchbox.tag` digest; this change is the source bump.
### Release note
```release-note
chore(talos): bump core/talos to Talos v1.13.5 and matchbox v0.11.0
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Chores
* Updated Talos infrastructure components to v1.13.5
* Updated matchbox service to v0.11.0
* Updated system extension firmware and driver components
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Refreshes the stale utility image references the issue flags (2021-era
builds carrying long-fixed `golang.org/x/crypto` / `golang.org/x/net`):
- `kube-rbac-proxy` `v0.11.0` → `v0.22.0` (etcd metrics scrape proxy,
`monitoring-agents`) on the `quay.io/brancz` registry that
`etcd-operator` already standardized on. Only the two core flags
`--secure-listen-address` / `--upstream` are used; both are stable
across the version range.
- `matchbox` base image `v0.10.0` → `v0.11.0` (`core/talos` PXE image).
v0.11.0 only bumps butane and adds darwin arm64 artifacts; the `COPY`
asset paths are unchanged.
- `alpine/k8s` tools image `1.33.4` → `1.36.2`, applied to **every**
non-vendored reference so the repo runs a single current tools-image
version: seaweedfs resize/kubectl hooks, the cozystack-api post-upgrade
hook, the installer, the vm-disk and vm-instance resize hooks, the
vertical-pod-autoscaler CRD-install override, and the e2e cilium leak
healer. The two digest-pinned refs (installer, e2e healer) get the
matching multi-arch digest `sha256:44ef4942…`.
**Note on the issue text:** #2903 cites the seaweedfs `alpine/k8s` ref
as `1.28.4`, but that value only exists as the **vendored** subchart
default (`charts/seaweedfs/values.yaml`), which is left untouched per
the vendoring rules. The effective runtime value comes from the
non-vendored `values.yaml` override, which was already at `1.33.4` and
is bumped here to `1.36.2`.
Verified: `helm template` renders the new tags (incl. the digest-pinned
installer ref); `helm unittest` passes for seaweedfs (7) and
cozystack-api (6); no fixture pins any of these tags.
Closes#2903
### Release note
```release-note
chore(images): refresh kube-rbac-proxy (v0.22.0), matchbox (v0.11.0), and alpine/k8s (1.36.2) utility images
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated container images across system components, operational hooks,
and monitoring utilities to newer stable versions.
* **Security**
* Hardened several lifecycle hook Jobs and related pod templates to run
as non-root, use `seccompProfile: RuntimeDefault`, disallow privilege
escalation, and drop all Linux capabilities.
* **Tests**
* Added Helm unit test coverage to verify hook Jobs’ non-root security
settings and related Job fields.
* **Documentation**
* Added `helm unittest`-based `test` targets for relevant charts to
support the new coverage.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Re-vendors the upstream `csi-driver-nfs` Helm chart from 4.11.0 to
4.13.3 (latest upstream release) via `make update`, picking up the
published security fixes in the bundled base layers and Go toolchain
that the issue enumerates.
All six CSI sidecar/plugin images move to current sig-storage releases:
nfsplugin v4.13.3, csi-provisioner v6.1.0, csi-resizer v2.0.0,
csi-snapshotter and snapshot-controller v8.4.0, livenessprobe v2.17.0,
node-driver-registrar v2.15.0.
The vendored tree is byte-for-byte identical to a fresh upstream pull
(no hand-edits). cozystack overrides are empty (`csi-driver-nfs: {}`)
and the platform pins the package by path, so nothing else needs
touching. New upstream defaults arrive with the bump and are
opt-in-safe: `enableSnapshotCompression`, the
`VolumeAttributesClass=false` feature-gate paired with the
provisioner/resizer majors, and a node-driver-registrar liveness probe.
`helm template` renders all images correctly.
Closes#2884
### Release note
```release-note
chore(nfs-driver): bump csi-driver-nfs chart and images to 4.13.3
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added support for generating multiple StorageClass resources from
chart values
* Enabled snapshot compression for controller operations
* **Updates**
* Upgraded the NFS CSI driver chart/image version to **4.13.3** and
updated related container images
* Improved node-side setup with node-specific DNS handling and enhanced
node-driver-registrar health/liveness probing (including configurable
timeouts)
* **Configuration Enhancements**
* Extended CSI feature gates and improved StorageClass handling
(conditional annotations and per-class settings)
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Bumps the Keycloak server image from `26.5.2` to `26.6.3` (latest
upstream stable, published 2026-06-04), picking up the published
security fixes the issue enumerates (patched Netty 4.1.135+/4.2.15+ and
the bundled-package CVE fixes).
Keycloak 26.6 adds zero-downtime patch upgrades and startup/liveness
probes that report `UP` during DB migrations (smoother rolling updates
on Kubernetes). Targeting 26.6.3 specifically — 26.6.0/26.6.1 shipped a
migration-persistence bug (server exits with code 1 after an async realm
migration) that later patches fix.
The chart runs a plain Keycloak StatefulSet with no custom browser flows
or realm import, so the `MigrateTo26_6_0` realm migration and the 26.6
runtime breaking changes (outbound HTTP redirects now opt-in, stricter
WebAuthn attestation, SAML REDIRECT inflate capped at 128KB) don't
affect chart-managed config. The StatefulSet env (`KC_DB`,
`KC_CACHE=ispn`, `KC_PROXY_HEADERS`, health endpoints) stays valid in
26.6.
Verified locally: `helm unittest` 2/2 pass; `helm template` renders the
new image with cluster values.
Closes#2878
### Release note
```release-note
chore(keycloak): bump Keycloak server image to 26.6.3
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated the Keycloak container image to version 26.6.3.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What this PR does
Cozystack enables Cilium's host firewall by default while the Cilium
IPv6 datapath stays disabled (`ipv6.enabled=false`). In upstream Cilium
this combination drops all node IPv6 on managed devices as "Unsupported
L3 protocol" (`DROP_UNKNOWN_L3` in `bpf_host.c`) before any policy
evaluation, in both directions. This breaks ICMPv6 Neighbor Discovery —
and with it all node-level IPv6, e.g. BGP unnumbered over link-local
addresses on L3 fabrics. No `CiliumClusterwideNetworkPolicy` can allow
this traffic, because the drop happens before policy enforcement
(upstream report: cilium/cilium#33155, closed stale).
The cozystack cilium image now carries a minimal BPF patch that passes
IPv6 to the kernel stack instead, mirroring the behavior with the host
firewall disabled:
- `packages/system/cilium/images/cilium/patches/` — three `ETH_P_IPV6`
passthrough cases under `#ifndef ENABLE_IPV6` in `bpf_host.c`. The
fourth `DROP_UNKNOWN_L3` site (`from_host_to_lxc`) is intentionally not
covered: bpf_lxc drops IPv6 without the v6 datapath regardless, so a
passthrough there restores nothing.
- The multi-stage Dockerfile applies the patch with `patch --fuzz=0`
plus a marker-count check, so upstream drift fails the image build
loudly.
- `make update` dry-runs the patch against the freshly vendored upstream
tag, so a cilium version bump surfaces drift immediately.
- `values.yaml` documents the consequence: Cilium host policies apply to
IPv4 only; node IPv6 is not filtered by Cilium.
The same fix was submitted upstream: cilium/cilium#46473. The local
patch is carried until it lands in a release Cozystack ships.
Verification: the image builds and contains the patched source; a
corrupted patch context fails the build with a clear error; the upstream
variant of this change passes new BPF unit tests that fail without the
fix with exactly the "Unsupported L3 protocol" drop from the field
report; existing host-firewall and IPv6 BPF tests still compile. PR e2e
exercises runtime BPF compilation of the patched source, since the agent
compiles `bpf_host.c` at startup.
Docs: cozystack/website#574
Closes#2806
### Screenshots
Not a UI change.
### Release note
```release-note
fix(cilium): node IPv6 (ICMPv6 Neighbor Discovery, BGP unnumbered over link-local) now works with the host firewall enabled; Cilium host policies apply to IPv4 only, node IPv6 is not filtered by Cilium
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Pass IPv6 traffic to the kernel stack when the Cilium IPv6 datapath is
disabled, preventing it from being treated as an unknown L3 protocol.
* **Documentation**
* Added clarification on host firewall behavior: with hostFirewall
enabled and IPv6 datapath disabled, policies apply to IPv4 only.
* **Chores**
* Improved the Cilium image build/update flow by validating the IPv6
patch against the upstream Cilium version to ensure compatibility.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
- talos-reconcile-job: emit a `---` separator inside the nodeGroups
range so a tenant with multiple node groups renders valid
multi-document YAML instead of two Jobs concatenated into one doc
- talos-reconcile + bootstrap-token jobs: add a restricted
securityContext (drop ALL caps, no privilege escalation, read-only
root fs) and CPU/memory requests+limits; drop the unused management
SA token mount on the bootstrap-token job, which only talks to the
tenant apiserver via the mounted admin kubeconfig
- migration 44: list Helm-managed resources by the
app.kubernetes.io/managed-by=Helm label, not meta.helm.sh/release-name
(an annotation, so it never matched as a --selector — the keep
annotation was silently never applied)
- cluster.yaml: fail fast on a malformed nodeHealthCheck.maxUnhealthy
rather than silently coercing it to 0 via `| int`
- config: make helm-install-disable-wait parsing genuinely
case-insensitive (EqualFold + trim) to match its documented contract
- capi-providers bootstrap/cpprovider Makefiles: guard the
patches/*.diff loop against an empty glob
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Add helm-unittest suites for the new Talos templates: MHC maxUnhealthy int-vs-percent rendering, the Talos<->Kubernetes support-matrix guard, the talos templates, and the ported kubelet-reservation math; restore the gpu=on node-label assertions. Remove the obsolete containerd-config-path test and fixtures. Raise tenant control-plane wait timeouts in the e2e runner for Talos PKI + sidecar boot.
Co-authored-by: Andrei Kvapil <kvapss@gmail.com>
Co-authored-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Migration 44 pins Helm-managed KubeadmConfigTemplates with resource-policy=keep so Helm cannot prune them mid-rollover; migration 45 bumps tenants on spec.version v1.30 to v1.31 ahead of the Talos support-matrix guard. Both stamp cozystack-version with its deletion-protection label. targetVersion is bumped to 46.
Co-authored-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Parse a new release.cozystack.io/helm-install-disable-wait annotation in start.go and apply it as Install/Upgrade.DisableWait in rest.go, so helm-controller no longer blocks post-install hooks on in-tenant addon readiness. This breaks the reconcile-hook chicken-and-egg where the hook that creates the worker TalosConfigTemplate was gated behind addons that need workers to schedule. Covered by a config table test.
Co-authored-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: IvanHunters <xorokhotnikov@gmail.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Switch tenant worker bootstrap from Ubuntu+kubeadm to Talos. MachineDeployment.bootstrap moves from KubeadmConfigTemplate to a TalosConfigTemplate produced by a post-install/upgrade reconcile hook, which also materialises the kubeadm-format bootstrap-token Secret in the tenant kube-system. Workers boot from the Talos openstack image via a CDI DataVolume; the system disk is virtio-blk with logical=512/physical=4096 so 4Ki-native backends (LINSTOR/DRBD) and SeaBIOS both work; the separate kubelet disk is dropped. Pod/service CIDRs, dnsDomain, controlPlane endpoint and cilium k8sServiceHost are pinned to the tenant ranges / Kamaji apiserver ClusterIP to survive the DNS chicken-and-egg at bootstrap. Adds a Talos<->Kubernetes support-matrix fail() guard and drops v1.30. Removes the dead ubuntu-container-disk build chain and the orphaned copy-patch-containerd template.
Co-authored-by: IvanHunters <xorokhotnikov@gmail.com>
Co-authored-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Generate Talos PKI (Ed25519 CA + trustd TLS) via cert-manager and stable random Talos secrets (token, clusterId, clusterSecret, bootstrapToken) using the helm lookup-and-reuse pattern. Build the talos-csr-signer sidecar from a pinned source commit, digest-pinned, with resources and securityContext.
Co-authored-by: IvanHunters <xorokhotnikov@gmail.com>
Co-authored-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Rebuild the Kamaji control-plane provider from upstream v0.19.0 with a backport of additionalServicePorts (upstream PR #347), exposing KamajiControlPlane.spec.network.additionalServicePorts so trustd (50001/TCP) can be published on the apiserver Service. Image is built from source and pinned by digest; the 0.17-0.19 release series is registered in metadata.
Co-authored-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
entityOperator.topicOperator/userOperator carried no resources, so in tenant
namespaces (the LimitRange defaults containers to 128Mi) the JVM topic-operator
and user-operator are OOMKilled on startup. The entity-operator stays in
CrashLoopBackOff, KafkaTopics/KafkaUsers never reconcile, and on teardown topics
get stuck on the strimzi.io/topic-operator finalizer. Set explicit requests/limits
(256Mi/512Mi) so they no longer inherit the namespace default; add a template test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
## What this PR does
Temporary revert. v1.5.0 restored persistent EFI/TPM state for the
`windows.11` / `windows.2k22` / `windows.2k25` profiles. With
persistence on, KubeVirt creates a backend-storage PVC
(`persistent-state-for-<vm>`) which, on the default `replicated`
StorageClass, is **ReadWriteOnce** — it pins the VM to its node and
**blocks live-migration and node drains**. With `evictionStrategy:
LiveMigrate` this can stall cluster upgrades. See #3005.
This strips persistent EFI/TPM from the preferences again — but via `yq
del` instead of the original `sed -d`, so an emptied `preferredTPM`
stays `{}` (the v1.8 CRD rejects `null`, which is the bug the original
strip caused). **Secure Boot and the vTPM remain present, just
non-persistent** — Windows VMs still boot; they just don't persist
EFI/TPM across reboots.
⚠️ **Temporary stopgap** until vm-state can request an RWX backend —
either RWX-Block via the upstream KubeVirt change
(kubevirt/kubevirt#18215), or an RWX-Filesystem `vmStateStorageClass`.
Once that lands, persistence can be re-enabled with live-migration
intact.
### Screenshots
No UI changes.
### Release note
```release-note
fix(kubevirt-instancetypes): temporarily disable persistent EFI/TPM state to unblock live-migration of Windows VMs. Persistence created a ReadWriteOnce backend-storage PVC on the default storage class, pinning the VM to its node. Secure Boot and vTPM remain available (non-persistent); to be re-enabled once vm-state can use RWX storage.
```
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Updated Windows virtual machine preferences to enable live migration
and drain operations
* Fixed compatibility issues with KubeVirt v1.8 virtual machine
preference configurations
* Removed persistent settings from TPM and EFI configurations to prevent
blocking behaviors on Windows 11 and Windows Server 2022/2025 variants
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Address review feedback from gemini-code-assist on SecretsTab.tsx: guard the
copy button on navigator.clipboard so it is disabled and a no-op when the API
is unavailable (plain-HTTP contexts), instead of throwing a TypeError.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Address review feedback from gemini-code-assist on ResourceQuotasField.tsx:
parseSize coerces val to a string first so a numeric quota from user-authored
YAML (e.g. cpu: 10) no longer crashes the edit form with "val.endsWith is not
a function".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Address review feedback from gemini-code-assist on ExternalIpsPage.tsx: add
enabled: !!tenantNamespace to the services useK8sList so it does not issue a
cluster-wide /api/v1/services request (403 for non-admin tenants) before the
tenant namespace is known.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Address review feedback from gemini-code-assist on DynamicOptionsWidget.tsx:
gate the useK8sList options query with enabled: !!tenantNamespace so it does
not fire a cluster-wide request to core.cozystack.io options (403 for
non-admin tenants) while the tenant namespace is still resolving.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Mirrors the former cozystack-ui test workflow: pnpm typecheck + unit tests,
gated to changes under packages/system/dashboard/images/console.
pnpm/action-setup reads the pnpm version from package_json_file (the console
workspace manifest) since the monorepo root has no package.json.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Move the console SPA source into the monorepo at
packages/system/dashboard/images/console so the UI versions and ships in
lockstep with the platform, removing the cross-repo digest-bump PRs and the
version drift between the two repositories.
Snapshot of cozystack/cozystack-ui main at 8ef45a4; full history remains in
that repository (to be archived). The Makefile now builds the console image
from this in-tree context instead of cloning the external repo at build time:
dropped clone-console/clean-console and the CONSOLE_REPO/CONSOLE_BRANCH
variables; the built digest is still pinned into values.yaml by
update-values-console. .helmignore already excludes images/*/* so the source
never enters the Helm chart.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Raise the OpenSSF Scorecard Token-Permissions and Pinned-Dependencies
checks (both currently 0/10) ahead of CNCF Incubation due diligence:
- Declare a top-level read-only default (permissions: contents: read) in
every workflow, plus an explicit per-job permissions: block that grants
only the writes that job actually needs. Workflows that previously held
write scopes at the workflow level (backport, pr-labeler, pr-size,
stale) now hold them at job level instead.
- Pin every GitHub-owned and third-party action to a full commit SHA with
a version comment. scorecard.yml was already pinned in #2721.
No triggers, job graph, or step logic change; only token scopes and
action refs. Self-hosted release jobs keep the exact write scopes they
already declared.
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
Assisted-By: Claude <noreply@anthropic.com>
The full-matrix PR run validated the decomposition functionally (green
install + 21/22 app tests on the matrix-built tree), stronger evidence
than the file-set parity diff would give — and it avoids running the
serial make build the parity job exists to compare against. SBOM stays
capability-only (common-envs.mk) until an OCIR referrers probe is run
when SBOM is actually pursued.
Refs #2937
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
finalize (and therefore e2e, which needs it) now depends on the checks
job succeeding, so a red unit/controller test skips the expensive
install+e2e path instead of running it for ~1h. Restores the gating the
old in-build-job tests gave, without re-coupling the cheap parallel
image builds.
Refs #2937
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
The "Pin the e2e management cluster Kubernetes version" item is no longer
in-flight — it is merged and live in hack/e2e-prepare-cluster.bats
(--kubernetes-version v1.33.12). Remove it from the "not yet the merged
standard" section; its rationale lives in the bats comment.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
talosctl 1.13.5 now defaults to Kubernetes 1.36.2, so the comment's premise
— that talosctl's bundled default predates the KCM VAP nil-pointer fix — no
longer holds (1.36.2 already carries that fix). The reason e2e pins v1.33.12
is now that 1.36 is outside cozystack's supported range; reword to lead with
that and keep the KCM VAP fix as the secondary property v1.33.12 carries.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Moves the pinned Alpine runtime bases of the first-party images forward to
alpine:3.24 to clear the published musl / zlib advisories carried by the stale
layers:
- mariadb-backup: 3.20 -> 3.24
- cozystack-operator: 3.22 -> 3.24
- platform-migrations: 3.22 -> 3.24
- grafana-dashboards: 3.22 -> 3.24
- kubeovn-webhook: 3.21.3 -> 3.24 (also drops the over-specific patch pin in
favour of the minor-float convention used elsewhere)
- redis-operator: latest -> 3.24 (pins the previously-floating runtime base)
These rebuild on the release asset pipeline; the digests pinned in values.yaml
are re-pinned there on the next build, matching how the rest of the ~30
first-party images pick up the shared base.
Side effect for platform-migrations: its kubectl / helm come from the Alpine
repo, so the base bump moves them 1.33 -> 1.36 and 3.18 -> 3.19. Both are
current upstream stable and compatible with the management cluster; for the
cozystack migration scripts (apply / get / label / helm release ops) the newer
kubectl is in skew with the modern control plane.
The build-only `alpine AS source` stages (keycloak-operator,
objectstorage-controller) are left as-is: their final images are distroless, so
no Alpine layer ships. The s3manager base is owned by the separate bucket bump,
and kilo's base moves in its own image rebuild.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The comment justified upgradeCRDs: false by a kubectl-image-compatibility
problem in the upgrade-crds Job. That rationale is obsolete in velero 12.x:
the Job now runs the velero image natively, not a kubectl image. The real,
current reason the Job stays disabled is that CRDs ship via the chart's
crds/ directory, making the Job redundant. Correct both the values.yaml
override comment and the helm-unittest comment to match.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The unmarked CiliumNetworkPolicy fixture carried only an endpointSelector,
which the cilium.io/v2 CRD rejects — spec requires at least one of
ingress/ingressDeny/egress/egressDeny (anyOf), so kubectl apply failed
before the invisible-to-SecurityGroup assertion could run. Add a minimal
ingress rule so the fixture applies as a valid, unmarked policy.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Re-vendors the FoundationDB Kubernetes operator chart from v2.13.0 to v2.30.0
(chart 0.2.0 -> 0.3.0), 17 minor releases forward, picking up the published
security fixes. The CRD changes (FoundationDBCluster/Backup/Restore) are
additive only -- new fields, no property removals (only the controller-gen and
foundationdb.org/release version annotations change) -- so the apps/foundationdb
FDB CR stays valid against the new operator. cozystack overrides (globalMode,
nodeReadClusterRole) remain valid. The one removed CLI flag (genericclioption)
is not used by cozystack; the chart's rbac role binding is now unconditional
(previously globalMode-gated), a no-op for cozystack which sets globalMode=true.
Adds helm-unittest coverage (the package shipped none): pins the operator image.
Adaptations:
- Makefile: clone --branch v2.13.0 -> v2.30.0; add test target
- charts/: re-vendored (operator v2.30.0 + additive CRD schema)
- tests/fdb-operator_test.yaml: new helm-unittest image pin
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
The managed-service app deploys the system openbao chart, whose server
image follows that chart's appVersion (now v2.5.1). The app Chart.yaml
appVersion ships verbatim on the openbao app CR, so leaving it at 2.5.0
makes every instance misreport its running OpenBAO version.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Re-vendors the openbao-helm chart from 0.25.3 to 0.25.7 (app v2.5.0 -> v2.5.1),
the latest in the ^0.25 line the Makefile pins, picking up the v2.5.1 security
fix. cozystack overrides (injector + csi disabled) stay valid and render
nothing, so the changed surface is the openbao server StatefulSet image only.
Widening past 0.25.x to 0.28.x (app v2.5.5) would need a CHART_VERSION constraint
change plus a 0.26/0.27/0.28 changelog review and is intentionally left out.
Adds helm-unittest coverage (the package shipped none): pins the server image
and the injector/csi-disabled invariants.
Adaptations:
- charts/: re-vendored via make update (helm pull openbao ^0.25 -> 0.25.7)
- Makefile: add test target
- tests/openbao_test.yaml: new helm-unittest coverage
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Bumps every supported Kubernetes minor in the apps/kubernetes version map to its
latest upstream patch, picking up the published Go-stdlib / x/net fixes in the
control-plane component images:
- v1.35: v1.35.1 -> v1.35.6
- v1.34: v1.34.4 -> v1.34.9
- v1.33: v1.33.8 -> v1.33.13
- v1.32: v1.32.12 -> v1.32.13
v1.31 and v1.30 already track their latest patch (.14). The major/minor enum is
unchanged, so the generated values schema, CRD and README are untouched
(make generate is a no-op).
The version range is intentionally held at v1.30-v1.35 and does NOT advance to
v1.36: KubeVirt 1.8.2 rejects the kubelet checksum on Kubernetes 1.36 (int32 CRD
validation), leaving tenant VMIs stuck Scheduled. The kamaji bump to 26.6.4-edge
raises KubeadmVersion to v1.36.0, so hack/update-versions.sh would otherwise add
v1.36 here -- that expansion is deferred until the KubeVirt regression is fixed.
The script also caps the top minor at the exact KubeadmVersion (v1.35.0); v1.35
is set to the latest patch (v1.35.6) by hand instead, matching the existing
practice of running a patch above the kubeadm tool version.
The OS-package advisories in the scan live in the ubuntu-container-disk worker
images; those clear when the release pipeline rebuilds them on the floating
ubuntu noble/current base (no source change needed -- the base is not pinned).
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Per-app TLS issues a per-release self-signed CA, but the only objects
that carry ca.crt — the cert-manager CA and leaf Secrets — also carry
private keys. Granting a tenant read on those to obtain the trust
anchor also hands over a server or CA private key.
Add cozy-lib.tls.caCertSecret, which renders a canonical Opaque Secret
holding only ca.crt and labelled internal.cozystack.io/tenantresource=
true. The tenantsecret registry surfaces label-bearing Secrets under
core.cozystack.io/tenantsecrets, which the base tenant roles already
grant, so tenants reach the trust anchor without any grant on a Secret
that contains tls.key. The helper fails closed on empty input and
refuses any PEM carrying private key material.
Covered by helm-unittest in the cozy-lib test chart.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Refreshes the monitoring image anchors onto current upstream to clear the
published advisories carried by the stale pins.
- grafana image: base grafana/grafana 11.4.0 -> 11.6.15 (latest 11.x). The
rebuild clears the Go-dependency advisories in the grafana binary (x/crypto,
moby/spdystream, jackc/pgx/v5, russellhaering/goxmldsig, buger/jsonparser,
golang-jwt/jwt/v4, getkin/kin-openapi). It stays on the 11.x line rather than
12.x to keep the bundled panel plugins compatible (grafana-worldmap-panel is
deprecated upstream) and avoid a dashboard-schema migration.
- victorialogs-datasource plugin: v0.14.1 -> v0.28.0 (grafanaDependency
>=10.4.0, so it loads on 11.6.15).
- alerta-web: 9.0.4 -> 9.1.0, clearing the python cryptography advisory.
- images/grafana.tag: re-pinned to the rebuilt multi-arch digest.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Rebuilds the e2e test sandbox on current upstream to clear the published
advisories (containerd, helm, go-git, moby/spdystream, Go stdlib) carried by the
stale tool binaries and base layers:
- base: ubuntu 22.04 -> 24.04; netcat -> netcat-openbsd, since `netcat` is a
candidate-less virtual package on 24.04
- kubectl: 1.33.2 -> 1.33.13, staying on the 1.33 line that the e2e control
plane pins at v1.33.12, so client/server skew is unchanged
- talosctl: 1.10.4 -> 1.13.5, aligning the client with the v1.13.x Talos nodes
the sandbox provisions
- helm: 3.18.3 -> 3.21.2 (latest helm 3); the e2e flow drives the v3 CLI, so it
stays on the 3.x line rather than moving to the breaking 4.x
- yq: 4.44.3 -> 4.53.3
- values.yaml: re-pinned to the rebuilt multi-arch digest
crust-gather and cozyhr already track their latest releases; flux and mc install
the current release at build time.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Refreshes the core/talos asset/profile layer onto current upstream to clear the
published advisories the scanner flagged in the stale pinned images.
- profiles: regenerated by hack/gen-profiles.sh v1.13.5, moving the base
installer and every system extension to the v1.13.5 line (installer v1.13.0 ->
v1.13.5; amdgpu/i915/drbd/zfs to their -v1.13.5 builds; amd-ucode and the
firmware blobs to the 20260519/20260512 snapshots). v1.13.5 rebuilds the
installer on the Go 1.26.4 toolchain and current runtime (kernel, containerd,
runc, OpenSSL), clearing the Go and libcrypto advisories compiled into the
stale v1.13.0 installer.
- matchbox: base image quay.io/poseidon/matchbox v0.10.0 -> v0.11.0, clearing
the libcrypto3 advisories in the matchbox runtime.
cozy-talos ships no runtime templates -- it drives the node image / installer /
matchbox asset builds. The Talos installer and matchbox images are rebuilt from
these sources by the release asset pipeline (the privileged imager build), which
also re-pins the generated matchbox digest; this change is the source bump.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Aleksei Sviridkin