fix(kamaji): close Go stdlib and module CVEs in the shipped binary - #3033

No actionable comments were generated in the recent review. 🎉

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses multiple security vulnerabilities identified in the Kamaji manager binary. By updating the build source version and explicitly overriding specific Go module dependencies, the changes ensure that the resulting container image is free of known exploitable advisories that were previously present in the pinned dependencies.

Highlights

• Build Version Update: Advanced the Kamaji build source from 26.3.5-edge to 26.3.6-edge to leverage the latest Go 1.26.4 toolchain and resolve standard library vulnerabilities.
• Dependency Remediation: Forced updates for golang.org/x/net, golang.org/x/crypto, and go.opentelemetry.io/otel/sdk to patched versions during the build process to eliminate known CVEs in the compiled binary.

Verdict

LGTM with non-blocking notes.

Minimal, well-scoped image-rebuild patch: source bump 26.3.5-edge -> 26.3.6-edge plus a go get overlay placed correctly between git apply and go build, closing Go stdlib and three module advisories that the upstream tag still pins to vulnerable versions.

Findings

[NIT] packages/system/kamaji/images/kamaji/Dockerfile:1 — the golang:1.26 base floats, so the exact stdlib version embedded into the binary depends on whichever 1.26.x is current at image build time. Pre-existing across all sibling Dockerfiles in this repo, but worth tracking separately: pinning to golang:1.26.4 (or whichever patch is intended) would make the CVE-closing rebuild idempotent across release pipelines. Not a blocker.

Claim mismatches

• [PARTIAL] PR body claims source bump alone cannot close module advisories because no edge tag up to 26.6.4-edge ships the fixed versions. Spot-checked 26.3.6-edge upstream go.mod: golang.org/x/net v0.51.0, golang.org/x/crypto v0.49.0, go.opentelemetry.io/otel/sdk v1.41.0 — matches PR body, overlay is necessary. Did not exhaustively walk every tag between 26.3.6 and 26.6.4, but the lower bound holds, which is sufficient for the argument.

Caveats

• Binary / vendored chart drift. The Dockerfile builds from kamaji 26.3.6-edge, but packages/system/kamaji/charts/ is still vendored from 26.3.5-edge (last make update). Upstream diff 26.3.5-edge...26.3.6-edge adds an optional spec.networkProfile.advertiseAddress field to the TenantControlPlane CRD (feat: add advertiseAddress to NetworkProfile for split management/tenant addressing clastix/kamaji#1111) plus matching controller logic in internal/builders/controlplane/deployment.go and internal/resources/kubeadm_config.go. Verified existing-customer upgrade impact at code-path level: every new branch falls back to the prior address when advertiseAddress is unset, so for all in-cluster TenantControlPlane resources (which predate the field) the computed kube-apiserver Deployment spec, kubeadm endpoint, and cert SANs are byte-identical to the 26.3.5-edge binary. No rolling restart of tenant control planes, no cert regeneration. The only practical effect of the drift is that the new advertiseAddress feature is dormant in cozystack — set on a TenantControlPlane CR it gets silently pruned by the apiserver (standard CRD unknown-field pruning), so it appears configurable but is unreachable until make update refreshes the vendored chart. Worth either running make update to align the chart with the binary or noting the drift explicitly.
• Strictly for the stated CVE goal, the source-tag bump is incidental — recompiling on the current golang:1.26 toolchain against the previous 26.3.5-edge source would close the stdlib advisories on its own. The overlay closes the module advisories independently of the source tag. Bumping the tag is reasonable for staying current with upstream, but the PR body presents it as required for the stdlib fix when it isn't.

Red-team concerns

• Build determinism: kamaji upstream ships go.sum, go get @vX.Y.Z + go mod tidy mutates both go.mod and go.sum deterministically via MVS, so repeated builds against the same source tag produce the same module graph. No vendor/ directory means no parallel state to keep in sync. Acceptable.
• Transitive bump scope: go mod tidy may pull additional indirect bumps beyond the three named modules; this is expected and is what makes the overlay valid.
• Go version compatibility: target modules (x/[email protected], x/[email protected], otel/[email protected]) all declare go 1.25.0; upstream kamaji declares go 1.25.0; build toolchain is golang:1.26. No floor mismatch.
• values.yaml still pins v1.5.0@sha256:130d… for both image.tag and extraArgs[0]=--migrate-image=…. Fine: the image target in packages/system/kamaji/Makefile re-writes both fields on release build with the new digest. No PR change to chart values needed.

Recommended follow-ups

• Sibling Go-built images in packages/{core,system}/*/images/*/Dockerfile use the same floating golang:1.26[-alpine] base. If their first-party go.mod files import vulnerable x/net/x/crypto/otel/sdk versions, they need analogous bumps — but those live in the repo's own go.mod, so the correct lever is a direct dependency bump there, not a Dockerfile overlay. Out of scope for this PR; track separately if the scanner flags them.
• Release-note fenced block: the PR template under .github/PULL_REQUEST_TEMPLATE.md expects a populated ```release-note ``` fenced block. The PR body has the heading but no fenced block. No CI enforcement, but worth filling in for changelog tooling.