packages/system/kamaji/images/kamaji/Dockerfile (1)

2-2: Floating base image tags reduce build reproducibility.

Both golang:1.24 (line 2) and gcr.io/distroless/static:nonroot (line 21) are floating tags. Silent patch-level updates to either can change the compiled binary or the shipped runtime layer between two otherwise identical builds.

Pinning both to immutable digests (@sha256:...) is the standard mitigation for reproducible, auditable container builds:

♻️ Proposed fix to pin base images by digest

-FROM golang:1.24 as builder
+FROM golang:1.24@sha256:<digest> AS builder
 ...
-FROM gcr.io/distroless/static:nonroot
+FROM gcr.io/distroless/static:nonroot@sha256:<digest>

Retrieve the current digests with:

docker buildx imagetools inspect golang:1.24 --format '{{json .Manifest.Digest}}'
docker buildx imagetools inspect gcr.io/distroless/static:nonroot --format '{{json .Manifest.Digest}}'

Also applies to: 21-21

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/images/kamaji/Dockerfile` at line 2, The Dockerfile
uses floating base tags which break reproducibility; pin both base images by
replacing the identifiers "golang:1.24" (the builder stage FROM line) and
"gcr.io/distroless/static:nonroot" (the final stage FROM) with their immutable
digest forms (e.g. golang@sha256:... and
gcr.io/distroless/static@sha256:...)—obtain the correct digests via `docker
buildx imagetools inspect` as suggested and update those two FROM lines to the
corresponding `@sha256` digests so builds are deterministic and auditable.

packages/system/kamaji/charts/kamaji-crds/templates/kamaji.clastix.io_tenantcontrolplanes.yaml (1)

10-10: Use {{- to eliminate the spurious blank line under spec:.

The two leading spaces before {{ are preserved in the output, and nindent 2 prepends a newline, resulting in an empty line between spec: and the first CRD spec key. While valid YAML, using {{- strips the preceding whitespace so nindent 2 alone provides the correct formatting.

This pattern appears in all three CRD templates in this chart and should be updated consistently.

♻️ Proposed fix

 spec:
-  {{ tpl (.Files.Get "hack/kamaji.clastix.io_tenantcontrolplanes_spec.yaml") . | nindent 2 }}
+{{- tpl (.Files.Get "hack/kamaji.clastix.io_tenantcontrolplanes_spec.yaml") . | nindent 2 }}

Apply the same change to kamaji.clastix.io_datastores.yaml and kamaji.clastix.io_kubeconfiggenerators.yaml.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/kamaji/charts/kamaji-crds/templates/kamaji.clastix.io_tenantcontrolplanes.yaml`
at line 10, Replace the current tpl invocation that leaves a spurious blank line
after "spec:" by switching the opening action to a whitespace-trimming form;
specifically update the template expression using tpl (.Files.Get
"hack/kamaji.clastix.io_tenantcontrolplanes_spec.yaml") . | nindent 2 to use the
left-trimmed action (change the leading "{{" to "{{-") so nindent 2 no longer
inserts an extra blank line. Apply the same change to the equivalent tpl
invocations in the other two CRD templates (kamaji.clastix.io_datastores.yaml
and kamaji.clastix.io_kubeconfiggenerators.yaml) so all three use the
left-trimmed "{{-" form.

packages/apps/kubernetes/files/versions.yaml (1)

1-6: EOL status of included versions warrants an operator notice.

Kubernetes 1.32 entered maintenance mode on Dec 28, 2025, with an End of Life date of Feb 28, 2026 — this month. Releases 1.31 and older are listed as no longer supported by the upstream project.

The Kubernetes project currently maintains release branches only for the most recent three minor releases (1.35, 1.34, 1.33).

v1.32 will stop receiving upstream security patches in ~9 days; v1.31 and v1.30 are already past upstream EOL. If Cozystack's support policy intentionally extends beyond upstream EOL (e.g., for migration runway), consider adding a deprecation notice in the UI/docs for these versions so operators know to plan upgrades.

Additionally, Kubernetes 1.35 is the last release supporting containerd 1.x. Users must switch to containerd 2.0 or later before upgrading to the next Kubernetes version. This is worth surfacing as a release note for anyone upgrading worker nodes to v1.35.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/apps/kubernetes/files/versions.yaml` around lines 1 - 6, The
versions.yaml list includes v1.32, v1.31 and v1.30 which are at or past upstream
EOL and v1.35 is the last to support containerd 1.x; update the repository so
operators see this: add deprecation/EOL metadata or a linked notice for the keys
"v1.32", "v1.31", and "v1.30" (e.g., a deprecation flag and EOL date) and add a
release note/notice tied to "v1.35" informing users that containerd 1.x is
supported only up to v1.35 and they must migrate to containerd 2.x+ before
upgrading beyond v1.35; ensure this change is surfaced to UI/docs where
versions.yaml is consumed.

packages/system/kamaji/images/kamaji/patches/disable-datastore-check.diff (1)

1-24: Startup DataStore validation removed — confirm operational intent.

The regenerated patch now removes the datastoreutils.CheckExists call entirely (previously it just switched context; now neither import nor call remains). This means Kamaji will no longer fail fast at startup if the configured DataStore is unavailable. The file name makes the intent clear, but ensure monitoring/alerting compensates for the removed fail-fast guard.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/images/kamaji/patches/disable-datastore-check.diff`
around lines 1 - 24, The startup DataStore existence check was removed
(datastoreutils.CheckExists) causing Kamaji to no longer fail-fast if the
configured DataStore is unavailable; restore the original behavior by re-adding
the datastoreutils import and calling datastoreutils.CheckExists(ctx, scheme,
datastore) inside NewCmd (before the controllerReconcileTimeout validation),
returning the error if it fails; ensure the import alias matches datastoreutils
and the error handling returns the error up the stack so startup fails fast when
the DataStore is unreachable.

packages/system/kamaji/charts/kamaji/Chart.yaml (1)

2-2: appVersion: latest — verify intentional upstream versioning strategy.

Using latest as appVersion diverges from semver conventions (and from the previous v0.0.0). Given the ArtifactHub annotation at line 50 (Releasing latest chart at every push), this appears intentional for a rolling-latest track. Confirm this matches the intended upgrade path and that any downstream tooling (e.g., image-pinning logic) handles a non-semver appVersion correctly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/charts/kamaji/Chart.yaml` at line 2, The Chart.yaml
currently sets appVersion: latest which breaks semver expectations; confirm
whether the rolling-latest release strategy is intentional and either restore a
semver value (e.g., vX.Y.Z) in appVersion or add clear documentation/annotations
and update downstream tooling (image-pinning, upgrade checks, ArtifactHub
integrations) to accept non-semver values; check and update any code paths that
read Chart.yaml.appVersion (search for references to appVersion in Chart.yaml,
the ArtifactHub annotation, image-pinning logic, and release scripts) to ensure
they correctly handle the "latest" string or change it back to a proper semver.

packages/system/kamaji/charts/kamaji/values.yaml (1)

115-158: Add configurable livenessProbe and readinessProbe fields to kubeconfigGenerator for pattern consistency.

The main Kamaji controller exposes livenessProbe and readinessProbe as user-configurable top-level values (lines 26–39), but the kubeconfigGenerator block lacks these fields. While the deployment template only sets healthProbeBindAddress without probe configuration, adding explicit probe values would align with the established pattern and allow users to customize probe behavior if needed.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/charts/kamaji/values.yaml` around lines 115 - 158, Add
configurable livenessProbe and readinessProbe fields under the
kubeconfigGenerator values block so users can override probe behavior (similar
to the top-level livenessProbe/readinessProbe). Specifically, in the
kubeconfigGenerator section (which contains healthProbeBindAddress,
replicaCount, serviceAccountOverride, etc.) add livenessProbe: {} and
readinessProbe: {} with the same configurable shape used by the main controller,
ensuring the deployment template consumes these new keys instead of only
healthProbeBindAddress; update any references in the Kubeconfig Generator
deployment manifest to use kubeconfigGenerator.livenessProbe and
kubeconfigGenerator.readinessProbe.

packages/system/kamaji/charts/kamaji/templates/kubeconfiggenerator-deployment.yaml (1)

27-41: Missing liveness and readiness probes despite healthProbeBindAddress being configured.

The container has --health-probe-bind-address configured but no livenessProbe or readinessProbe are defined, unlike the main Kamaji controller. Without probes, Kubernetes cannot detect an unhealthy container and will not restart or route traffic accordingly.

♻️ Suggested addition (align with main Kamaji controller's probe config)

           resources:
             {{- toYaml .Values.kubeconfigGenerator.resources | nindent 12 }}
           securityContext:
             {{- toYaml .Values.kubeconfigGenerator.securityContext | nindent 12 }}
+          livenessProbe:
+            httpGet:
+              path: /healthz
+              port: {{ .Values.kubeconfigGenerator.healthProbeBindAddress | trimPrefix ":" }}
+            initialDelaySeconds: 15
+            periodSeconds: 20
+          readinessProbe:
+            httpGet:
+              path: /readyz
+              port: {{ .Values.kubeconfigGenerator.healthProbeBindAddress | trimPrefix ":" }}
+            initialDelaySeconds: 5
+            periodSeconds: 10

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@packages/system/kamaji/charts/kamaji/templates/kubeconfiggenerator-deployment.yaml`
around lines 27 - 41, Add livenessProbe and readinessProbe to the
kubeconfig-generator container spec (the container named "controller") so
Kubernetes can detect unhealthy instances; use HTTP probes that hit the health
endpoints (e.g., /healthz for liveness and /readyz for readiness) on the same
health port/address used by the --health-probe-bind-address flag (mirror the
main Kamaji controller probe configuration: set initialDelaySeconds,
periodSeconds, timeoutSeconds, failureThreshold/successThreshold), and place
these probe blocks alongside the existing resources and securityContext in the
container definition, wired to the chart values (e.g.,
.Values.kubeconfigGenerator.healthProbeBindAddress /
.Values.kubeconfigGenerator.healthPort or default port) so they respect
user-configured probe settings.

packages/system/kamaji/charts/kamaji-crds/templates/_helpers.tpl (1)

13-24: Rename kamaji.fullname to kamaji-crds.fullname for naming consistency.

This template defines kamaji.fullname but it is never used in the chart. The definition breaks the kamaji-crds.* naming convention that all other helpers follow (kamaji-crds.name, kamaji-crds.chart, kamaji-crds.certManagerAnnotation, kamaji-crds.labels). Either rename it to match the convention or remove it if it's truly unused.

♻️ Suggested rename

-{{- define "kamaji.fullname" -}}
+{{- define "kamaji-crds.fullname" -}}
 {{- if .Values.fullnameOverride }}
 {{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
 {{- else }}
 {{- $name := default .Chart.Name .Values.nameOverride }}
 {{- if contains $name .Release.Name }}
 {{- .Release.Name | trunc 63 | trimSuffix "-" }}
 {{- else }}
 {{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
 {{- end }}
 {{- end }}
 {{- end }}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/charts/kamaji-crds/templates/_helpers.tpl` around
lines 13 - 24, The helper currently defines "kamaji.fullname" which breaks the
chart's "kamaji-crds.*" helper naming convention; rename the template definition
from "kamaji.fullname" to "kamaji-crds.fullname" (or delete it if truly unused)
and update any internal references to use "kamaji-crds.fullname" so it matches
the existing helpers like "kamaji-crds.name", "kamaji-crds.chart", and
"kamaji-crds.labels"; ensure the definition body (logic using
.Values.fullnameOverride, $name, .Release.Name, trunc/trimSuffix) remains
identical after the rename.

packages/system/kamaji/images/kamaji/Dockerfile (1)

2-2: Consider pinning to a specific Go patch version for reproducible builds.

golang:1.26 is a floating tag. Once 1.26.1 is published, the tag resolves to a different layer, silently changing the build toolchain. Pinning to golang:1.26.0 (or a digest) prevents inadvertent toolchain drift between builds.

♻️ Proposed fix

-FROM golang:1.26 AS builder
+FROM golang:1.26.0 AS builder

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/images/kamaji/Dockerfile` at line 2, The Dockerfile's
FROM instruction uses a floating Go tag ("FROM golang:1.26 AS builder"); change
it to a pinned patch version (e.g., "golang:1.26.0") or a digest to ensure
reproducible builds by preventing toolchain drift—update the FROM line in the
Dockerfile accordingly.

packages/system/kamaji/images/kamaji/Dockerfile (1)

2-2: Consider pinning to a specific patch-version tag for reproducible builds

golang:1.25 is a floating minor-version tag that will silently resolve to different patch images over time, making builds non-reproducible. Pinning to a specific patch (e.g., golang:1.25.7) or an image digest ensures the same toolchain is used on every build.

♻️ Proposed fix (pin to specific patch version)

-FROM golang:1.25 AS builder
+FROM golang:1.25.7 AS builder

Or, for maximum reproducibility, use a digest:

-FROM golang:1.25 AS builder
+FROM golang:1.25.7@sha256:<digest> AS builder

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@packages/system/kamaji/images/kamaji/Dockerfile` at line 2, Update the Docker
base image specification to pin the floating tag "FROM golang:1.25" to a
specific patch version or digest so builds are reproducible; replace the
floating tag with a concrete patched tag like "golang:1.25.7" or use an image
digest (sha256) in the same FROM instruction to ensure the same toolchain is
used for every build.