feat(kubernetes): let CDI trust a self-hosted Talos image factory - #3797

What this PR does

Adds talos.imageFactoryCA to the kubernetes chart, so CDI can verify a Talos Image Factory served with a certificate from an internal CA. Fixes #3796.

The gap

talos.imageFactoryURL is documented for self-hosted factories and mirrors in "air-gapped, rate-limited, or flaky-egress environments". In such an environment the endpoint is normally served by the organisation's own CA, and CDI — trusting only its system store — refuses the import with x509: certificate signed by unknown authority. The DataVolume never completes, no worker joins, and the release sits in install until it times out.

DataVolume.spec.source.http.certConfigMap exists for exactly this and has since the beginning. The chart just never filled it in: templates/cluster.yaml rendered url alone, and no value reached the field. certConfigMap appears nowhere in this repository.

The change

One optional value on the existing talos group:

talos:
  imageFactoryURL: "https://factory.example.com"
  imageFactoryCA: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

Set, it renders a ConfigMap in the release namespace and points the DataVolume at it. Empty — the default — renders no ConfigMap, no certConfigMap key, and no volume: I diffed helm template against main with the field unset and the output is identical byte for byte.

Why the PEM rather than a ConfigMap name

certConfigMap must live in the DataVolume's namespace, so a name-only field would ask the user to create an object in the tenant namespace by hand — which the dashboard offers no path for, and which splits one decision across two places in a GitOps repository. Taking the PEM keeps it inside the application's values like every other setting. A name-reference variant is a small change from here if maintainers prefer it.

Why this cannot break an existing release

CDI appends the bundle to the system pool rather than replacing it — x509.SystemCertPool() followed by AppendCertsFromPEM over every file in the mounted directory (pkg/importer/http-datasource.go). A release that also pulls from a publicly-trusted endpoint keeps verifying. This is the same distinction #3385 drew between SSL_CERT_DIR and AWS_CA_BUNDLE.

The field is optional with an empty default, so values.schema.json gains a property and no required entry.

Fail-closed guards

The value is emitted verbatim into a ConfigMap that anything able to read the namespace can read, so the helper refuses private key material and anything that is not complete PEM certificate blocks — including the realistic accident of cat ca.pem key.pem pasted into the field, where a valid leading certificate must not carry a trailing key through.

Those rules restate the ones in cozy-lib.tls.caCertSecret. I kept them local so the failure names talos.imageFactoryCA rather than that helper's caCert parameter, and because the object here is a ConfigMap consumed by CDI in-namespace rather than a tenant-published trust anchor. If you would rather have one shared guard in cozy-lib, say so and I will extract it.

A non-string value is not guarded in the template — values.schema.json rejects it before rendering starts.

Testing

tests/talos_image_factory_ca_test.yaml, 11 cases: unset renders nothing on both sides; set renders the ConfigMap and a certConfigMap naming it; a whitespace-only value counts as unset; multi-certificate chains work; and each guard is pinned on the input that trips it. Full suite for the package: 216 passed.

make generate run in the package; regenerated values.schema.json, README.md, api/apps/v1alpha1/kubernetes/types.go and the kubernetes-rd CRD are committed.

Not yet exercised end-to-end against a live internal factory — I can report back once it has been.

Not in this PR

packages/apps/vm-disk/templates/dv.yaml renders source.http.url with the same gap. Left alone to keep this reviewable; happy to follow up if this shape is accepted.

Screenshots

Not a UI change.

Downstream repositories

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up: Kubernetes: model the new talos.imageFactoryCA field (upstream cozystack#3797) terraform-provider-cozystack#31
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:

Walked the trigger map against the diff:

• terraform-provider-cozystack — ticked. The diff adds a field to packages/apps/kubernetes/values.schema.json, which the trigger map names directly ("Add, remove or rename a field in an app's values.schema.json → the schema, the model, and the expand/flatten pair"). Filed as an issue rather than a PR there, matching the existing Move kubeapps cache reloading logic out of installer.sh #19 / Rolling update for Talos nodes #20 / Fix gitignore #26 pattern for upstream field additions.
• website — not ticked. No package is added, renamed or removed; the reference page for this app is regenerated from the package README.md by the release bot, and that README.md is regenerated and committed here.
• Every other repository — no path in the trigger map is touched: no hack/ move, no ApplicationDefinition change, no namespace or variant rename, no installer or platform values key, no telemetry metric, no annotation or label contract.

Release note

feat(kubernetes): add `talos.imageFactoryCA` so CDI can verify a self-hosted Talos Image Factory served with a certificate from an internal CA. Previously `talos.imageFactoryURL` could point at such a factory but the image import failed with `x509: certificate signed by unknown authority`, leaving worker nodes stuck in Provisioning. Set the CA in PEM form and the chart wires it into the worker DataVolume; leave it empty and nothing changes.

Summary by CodeRabbit

• New Features

  • Added optional talos.imageFactoryCA configuration for providing PEM CA certificates.
  • Worker image imports can now connect to HTTPS image factories using private or internal certificate authorities.
  • Added validation to reject invalid certificates, private keys, and incomplete PEM content.
  • The Kubernetes dashboard schema now exposes the new configuration field.

• Tests

  • Added coverage for valid certificate bundles, omitted values, and invalid certificate inputs.