Repository navigation
CKS: the binaries ISO builder bundles an unpinned autoscaler and CCM, and records nothing about what it contains #14648
Description
problem
scripts/util/create-kubernetes-binaries-iso.sh builds the CKS binaries ISO, but it does not pin two of the add-ons it bundles:
- Cluster autoscaler. The manifest is downloaded from the
masterbranch ofkubernetes/autoscaler(cluster-autoscaler/cloudprovider/cloudstack/examples/cluster-autoscaler-standard.yaml, next to a# TODO : Change the url once merged). The image bundled is whatever that manifest names, which isapache/cloudstack-kubernetes-autoscaler:latest. That tag was last pushed in March 2022 and is a 1.24.0-alpha development build. The cluster-autoscaler only supports the Kubernetes minor version it was released with, so every ISO for Kubernetes 1.25 or later ships an autoscaler built for a different Kubernetes version. - Cloud controller manager. The manifest comes from the
mainbranch ofapache/cloudstack-kubernetes-provider(deployment.yaml), and the image is whatevermainnames on the day of the build. ISOs built before December 2025 got v1.1.0 this way. v1.1.0 does not initialise nodes (Fix providerID implementation cloudstack-kubernetes-provider#58, fixed in v1.2.0).
So two ISOs labelled with the same Kubernetes version can contain different add-ons, and a rebuild can pick up a breaking change without anyone noticing. Nothing in the ISO records which versions it contains.
Most of the downloads also use curl -sSL or curl -L without -f, so a 404 is saved as the file and goes into the ISO.
#14598 fixes the same kind of download problem in the node-side scripts (deploy-provider, autoscale-kube-cluster, deploy-csi-driver), but leaves the ISO builder and the version pinning alone.
versions
4.22 and main. The autoscaler and CCM URLs are the same on both branches.
The steps to reproduce the bug
- Run
scripts/util/create-kubernetes-binaries-iso.shfor any Kubernetes version, e.g.1.31.14. - Mount the ISO and look at
autoscaler.yamlandprovider.yaml. - The autoscaler image is
apache/cloudstack-kubernetes-autoscaler:latestwhatever the Kubernetes version. The CCM image is whatevermainofcloudstack-kubernetes-providernamed that day.
What to do about it?
- Download the autoscaler manifest from the
cluster-autoscaler-<version>release tag that matches the ISO's Kubernetes minor version, and bundle that release's image. - Pin the CCM to a release tag (v1.2.0 or later) and bundle the image of that tag.
- Allow both to be overridden when building the ISO.
- Write a file into the ISO that lists what it contains.
- Use
curl -fso a failed download stops the build.
Activity
github-actions commentedon Nov 11, 2026
Warning
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
The CKS binaries ISO builder fetches the cluster autoscaler manifest from the
masterbranch, which names an image last pushed in 2022, and the cloud controller manager frommain, so two ISOs for the same Kubernetes version can carry different add-ons. The reporter asks for release-tag pinning, overridable versions, a manifest file in the ISO, andcurl -fon downloads. This is an improvement request, not a runtime failure.📊 Assessment
🔗 Similar issues
curlproblem on the node side💡 Notes and suggestions
scripts/util/create-kubernetes-binaries-iso.shfor two Kubernetes versions and compareautoscaler.yamlandprovider.yaml.curl -fchange is small and could be split out from the version-pinning work.Add this agentic workflow to your repo
To install this agentic workflow, run