🤖 Generated by the Daily AI Assistant
Problem
#1559 added keyless cosign signature verification (spec.verify) to the app OCIRepository sources (wedding-app, ascoachingogvaner), signed by reusable-workflows/.github/workflows/publish-app.yaml via GitHub OIDC (Fulcio/Rekor). That closes the supply-chain gap for application artifacts.
The infrastructure source is still unverified. The flux-system OCIRepository — which carries the platform's own manifests (variables, infrastructure-controllers, infrastructure, apps Kustomizations all sourceRef it) — has no spec.verify. It's the single largest blast radius in the cluster (it defines every controller, policy, and gateway), yet source-controller will reconcile whatever is pushed to oci://…/manifests without verifying provenance. Upstream Helm OCI charts (hcloud-csi, longhorn, external-dns, openbao, …) are likewise unverified.
Why this isn't a one-line change
The infra manifests artifact is published by ksail --config ksail.prod.yaml workload push in cd.yaml — and (unlike the app artifacts) there is no signing step, so spec.verify can't simply be switched on; the artifact must be signed first. This also raises a portfolio question for KSail: should ksail workload push grow first-class keyless signing (an --sign / OIDC option), so signed publishing is a platform capability rather than a bolted-on cosign sign step? See applications/ksail.
Proposed direction (incremental, behaviour-preserving until the final switch)
- Sign the infra artifact on publish. Either (a) add a keyless
cosign sign step after ksail … workload push in cd.yaml using the same GitHub-OIDC identity pattern as publish-app.yaml, or (b) — preferred long-term — add signing support to ksail workload push and call it. Keep the single release → cd.yaml deploy path (no parallel workflows).
- Verify on the cluster. Add
spec.verify (keyless, matching the cd.yaml/KSail workflow signing identity) to the flux-system OCIRepository base. Roll out to local first, confirm Ready=True, then prod.
- (Follow-on, separate issue) evaluate cosign verification for the upstream Helm OCI charts where the chart publisher signs (Flux
HelmChart/OCIRepository .spec.verify).
Acceptance criteria
Rough size
M — investigation + a signing step + one base manifest change, rolled out local → prod. The KSail-native signing option (1b) is a separate, larger piece tracked on KSail if pursued.
Maintainer: this is a proposed roadmap epic from a first-ever platform strategy review — reshape, split, deprioritise, or close as you see fit. It deliberately extends your own #1559 rather than introducing a new pattern, and keeps the existing single deploy path.
Problem
#1559 added keyless cosign signature verification (
spec.verify) to the appOCIRepositorysources (wedding-app,ascoachingogvaner), signed byreusable-workflows/.github/workflows/publish-app.yamlvia GitHub OIDC (Fulcio/Rekor). That closes the supply-chain gap for application artifacts.The infrastructure source is still unverified. The
flux-systemOCIRepository— which carries the platform's own manifests (variables,infrastructure-controllers,infrastructure,appsKustomizations allsourceRefit) — has nospec.verify. It's the single largest blast radius in the cluster (it defines every controller, policy, and gateway), yet source-controller will reconcile whatever is pushed tooci://…/manifestswithout verifying provenance. Upstream Helm OCI charts (hcloud-csi,longhorn,external-dns,openbao, …) are likewise unverified.Why this isn't a one-line change
The infra manifests artifact is published by
ksail --config ksail.prod.yaml workload pushincd.yaml— and (unlike the app artifacts) there is no signing step, sospec.verifycan't simply be switched on; the artifact must be signed first. This also raises a portfolio question for KSail: shouldksail workload pushgrow first-class keyless signing (an--sign/ OIDC option), so signed publishing is a platform capability rather than a bolted-oncosign signstep? Seeapplications/ksail.Proposed direction (incremental, behaviour-preserving until the final switch)
cosign signstep afterksail … workload pushincd.yamlusing the same GitHub-OIDC identity pattern aspublish-app.yaml, or (b) — preferred long-term — add signing support toksail workload pushand call it. Keep the singlerelease → cd.yamldeploy path (no parallel workflows).spec.verify(keyless, matching thecd.yaml/KSail workflow signing identity) to theflux-systemOCIRepositorybase. Roll out tolocalfirst, confirmReady=True, thenprod.HelmChart/OCIRepository.spec.verify).Acceptance criteria
flux-systemOCIRepositorycarriesspec.verify; both clusters stayReady=Trueafter deploy (no reconciliation halt).docs/supply-chain note) so the verification identity is discoverable for future workflow-path changes.Rough size
M — investigation + a signing step + one base manifest change, rolled out local → prod. The KSail-native signing option (1b) is a separate, larger piece tracked on KSail if pursued.
Maintainer: this is a proposed roadmap epic from a first-ever platform strategy review — reshape, split, deprioritise, or close as you see fit. It deliberately extends your own #1559 rather than introducing a new pattern, and keeps the existing single deploy path.