The golden worker image catalog cannot import from a Talos Image Factory that is served with a certificate from an internal CA. #3797 fixed this for the per-pool import in kubernetes-nodes by adding talos.imageFactoryCA, but the catalog in packages/system/kubernetes-worker-image did not get the same option. Its templates/dv.yaml renders source.http.url and nothing else, and the chart has no CA value.
On a cluster whose kubernetesWorkerImage.imageFactoryURL points at such a factory, the golden DataVolume in cozy-public never imports. The importer fails with x509: certificate signed by unknown authority and CDI restarts it with back-off. With #4802, a pool on osImage.builtin that clones this golden is refused at render with "keeps failing to import", so the failure is visible instead of a hang. Still, osImage.builtin cannot work against this factory at all. The only workaround is osImage.factory on every pool, which is the per-pool network import the catalog exists to avoid.
Possible fix: an optional CA value on the worker-image chart, global plus a per-image override next to imageFactoryURL. The chart would render it into a ConfigMap in cozy-public and reference it from the golden's source.http.certConfigMap, validated with the existing cozy-lib.tls.validateCACert helper. The platform's kubernetesWorkerImage passthrough has to forward it. With an empty default nothing is rendered and existing goldens stay as they are.
One thing to handle: a golden DataVolume spec cannot be patched. The drift check in dv.yaml already refuses a changed URL, storage or class on an existing golden, and adding a CA to a live golden would need the same treatment.
The golden worker image catalog cannot import from a Talos Image Factory that is served with a certificate from an internal CA. #3797 fixed this for the per-pool import in kubernetes-nodes by adding
talos.imageFactoryCA, but the catalog inpackages/system/kubernetes-worker-imagedid not get the same option. Itstemplates/dv.yamlrenderssource.http.urland nothing else, and the chart has no CA value.On a cluster whose
kubernetesWorkerImage.imageFactoryURLpoints at such a factory, the golden DataVolume incozy-publicnever imports. The importer fails withx509: certificate signed by unknown authorityand CDI restarts it with back-off. With #4802, a pool onosImage.builtinthat clones this golden is refused at render with "keeps failing to import", so the failure is visible instead of a hang. Still,osImage.builtincannot work against this factory at all. The only workaround isosImage.factoryon every pool, which is the per-pool network import the catalog exists to avoid.Possible fix: an optional CA value on the worker-image chart, global plus a per-image override next to
imageFactoryURL. The chart would render it into a ConfigMap incozy-publicand reference it from the golden'ssource.http.certConfigMap, validated with the existingcozy-lib.tls.validateCACerthelper. The platform'skubernetesWorkerImagepassthrough has to forward it. With an empty default nothing is rendered and existing goldens stay as they are.One thing to handle: a golden DataVolume spec cannot be patched. The drift check in
dv.yamlalready refuses a changed URL, storage or class on an existing golden, and adding a CA to a live golden would need the same treatment.