Sidero Labs Ships CA Rotation and Cosign Verification for Talos and Omni — What's Automatic, What's Manual, and What Still Breaks

Import a Talos cluster into Sidero Labs' Omni and, until early 2026, the cluster's root certificate authority stayed exactly what it was before the import: whatever CA the original provisioning process generated. Omni would manage the cluster going forward, but the entity that first stood it up — a script, a colleague who's since left, a vendor's onboarding flow — kept a certificate authority that could still mint valid credentials for it. Sidero's Q1 2026 Talos/Omni release closes that gap with two features: CA rotation for imported clusters, and a native, OS-level Cosign image-verification gate. Neither one works quite the way its marketing copy implies, and the second one shipped with a bug that broke etcd on boot. Here's what each actually does.

CA rotation is a command you run, not a step that runs itself​

The framing you'll see repeated — "Omni rotates the cluster's root of trust on import" — overstates what happens. Importing a cluster into Omni applies a tainted-by-importing label to it, flagging that its CA predates Omni's management. Removing that taint requires an operator to explicitly trigger rotation:

omnictl cluster -n <cluster-name> secret rotate talos-ca
omnictl cluster -n <cluster-name> secret rotate kubernetes-ca
omnictl cluster -n <cluster-name> secret rotate status

Nothing about the import itself starts this. If nobody runs those two commands, the imported cluster keeps trusting whatever CA it arrived with, indefinitely.

When you do run it, rotation happens in three stages per CA:

1. PRE-ROTATE — a new CA certificate is added as "accepted" alongside the existing one, so nodes trust both during the transition.
2. ROTATE — the issuing CA swaps to the new certificate; the old one stays "accepted" so certificates already issued from it keep validating.
3. POST-ROTATE — the old CA is dropped from the accepted set, and any credential it minted stops being trusted anywhere in the cluster.

The two CAs behave differently in practice. Rotating the Talos API CA needs no reboots and doesn't interrupt cluster-internal traffic, but any pod that talks to the Talos API directly needs a manual restart to pick up the new trust chain. Rotating the Kubernetes API CA is more disruptive: it doesn't require reboots either, but it does trigger automatic restarts of the control-plane components (kube-apiserver, kube-controller-manager, kube-scheduler) and can briefly interrupt intra-cluster communication while certificates propagate — and again, pods need a manual restart to use the refreshed CA. Only one rotation can run at a time, and both commands support --wait-timeout and a fire-and-forget --wait=false mode for scripting.

That last detail matters more than it looks. If CA rotation is a two-command, operator-triggered action rather than something import does for you, it's exactly the kind of step that gets skipped under deadline pressure and then forgotten — the imported cluster works fine either way, so there's no error to notice. A fleet runbook (or better, the automation that performs the import) needs to call both rotation commands as a mandatory last step of onboarding any externally-provisioned cluster, not leave it as a manual follow-up someone might get to.

It's also worth being precise about what rotation buys you and what it doesn't. Swapping the CA revokes the authority to mint new valid certificates — it doesn't retroactively invalidate anything an attacker with the old root already exfiltrated and used before POST-ROTATE completes, and it does nothing about credentials the old provisioner issued to systems outside the cluster (a CI pipeline holding a long-lived kubeconfig signed by the old CA, for instance, which needs its own separate reissue). Rotation closes the ongoing backdoor — the old CA can no longer mint anything new — but a genuinely compromised import still needs an audit of what the old CA already signed, not just a rotation and a checked box.

Cosign verification moves the gate from admission time to boot time​

The second feature is Talos's native image-signature verification, configured through an ImageVerificationConfig machine config document. It's deny-by-default: define a rule matching an image reference, and any image that matches but doesn't verify against the rule's signature is refused — not deployed with a warning, refused. A rule can use keyless verification against an OIDC issuer or a pinned public-key certificate:

apiVersion: v1alpha1
kind: ImageVerificationConfig
rules:
  - image: registry.k8s.io/*
    keyless:
      issuer: https://accounts.google.com
      subject: krel-trust@k8s-releng-prod.iam.gserviceaccount.com
  - image: my-registry/*
    publicKey:
      certificate: |-
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----

What makes this meaningfully different from the Cosign verification most Kubernetes clusters already run — Sigstore's policy-controller or Kyverno's verifyImages rules — is where the check happens. Both of those are admission controllers: they inspect a Pod object as it's submitted to the API server and can block it before the scheduler ever places it. That covers ordinary Deployments and their images, but it structurally can't see everything a node runs. Static pods (kube-apiserver, etcd, the components that boot before the API server exists to admit anything against), the CNI plugin image, the kubelet binary itself, and the Talos installation image never pass through API-server admission at all — they're pulled and started directly by the node. ImageVerificationConfig runs at that layer instead, at the CRI level on the node doing the pulling, which is the only place these boot-time images are ever visible to check in the first place.

That's the theoretical win. In practice, the feature is new enough to still have sharp edges. Shortly after Talos v1.13.2 shipped, an operator running the exact registry.k8s.io/* keyless rule from Sidero's own example hit a cluster that wouldn't boot: etcd failed to start with image verification failed: no valid signature found: bundle tag not found, even though cosign verify against the same image tag succeeded cleanly from a workstation (siderolabs/talos#13342). The verifier was looking for a .sig manifest tag that didn't exist for that image rather than performing the lookup cosign itself used. The workaround was an explicit skip: true rule for registry.k8s.io/etcd layered ahead of the broader wildcard rule — and it still needed a reboot to take effect. Sidero fixed the root cause in a follow-up PR, but the incident is worth keeping in mind: this is a deny-by-default gate sitting in front of etcd's own boot path, and its own example configuration was enough to trip it on a component the cluster cannot start without. Anyone turning this on should stage it on a non-production cluster first and watch a full reboot cycle before trusting it against a registry.k8s.io/*-style wildcard in production.

Staged upgrades round out the third leg​

The same release cycle also shipped staged, health-gated upgrades: a node downloads the new installer image and writes the new kernel and initramfs to the inactive boot partition while continuing to run its current workloads — nothing is disturbed until an explicit reboot is triggered. Metadata written alongside the staged image is checked very early in the next boot; if the new image doesn't pass its health check within the configured timeout, the bootloader automatically falls back to the previous, known-good partition on the following reboot rather than leaving the node stuck on a broken upgrade.

Paired with the other two features, the intent is a coherent pipeline: an image has to verify against a Cosign policy before it's allowed to run at all, an upgrade stages and health-checks itself before it's trusted, and a cluster's inherited trust gets explicitly revoked once Omni takes over management. Each piece closes a real gap. None of them closes it by itself.

What a self-hosted Cluster-API fleet still has to build​

For a platform running Talos underneath a Cluster-API-managed fleet on owned hardware — the setup bex uses on Hetzner via CAPH — these three features are a meaningfully stronger starting point than Talos had before, but none of them is a finished answer on their own:

• CA rotation has to be automation, not a runbook line. Because it's operator-triggered rather than import-triggered, a platform that imports externally-provisioned clusters (or migrates fleet ownership between control planes) needs to call secret rotate talos-ca and secret rotate kubernetes-ca as a scripted, non-optional step of its own onboarding flow — treating the tainted-by-importing label as a gate that blocks the cluster from being marked production-ready, not an informational tag nobody checks.
• ImageVerificationConfig protects the platform's own boot path, not tenant workloads. It verifies the Talos installer, kubelet, CNI, and control-plane images — the platform team's own supply chain. A multi-tenant PaaS running arbitrary tenant containers still needs its own admission-time policy (Kyverno or Sigstore's policy-controller are the standard picks) for tenant images, since tenants aren't shipping Sidero-signed artifacts and the node-level gate has no opinion about what a tenant's own registry contains.
• A passing boot health check isn't the same as a healthy cluster. Talos's staged-upgrade health check confirms the node itself came back up; it says nothing about whether kubelet successfully rejoined the cluster, whether tenant pods are scheduling normally, or whether an upgraded node pool is actually serving traffic correctly. A platform that wants to trust staged upgrades at fleet scale needs its own post-upgrade health gate layered on top of Talos's boot-level one before promoting a rollout past a canary node pool.

None of that is a knock on the release — closing the split-trust window on cluster import and moving image verification below the admission layer are both real, useful primitives, and the staged-upgrade rollback path is exactly the kind of safety net a bare-metal fleet with no managed rollback service underneath it should want. The honest read is narrower than the announcement: Sidero built the gate. What runs the gate — and what happens after something gets through it or fails behind it — is still the fleet operator's job.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, provisioned through Cluster API and running Talos Linux underneath. Star the repo on GitHub or deploy your first app today.