Ceph: rotation cephx aes256k des clients kernel Talos (csi-cephfs-node/csi-rbd-node) — cible Talos v1.13.10

## Contexte

Suite à [CVE-2025-30156](https://docs.ceph.com/en/latest/security/CVE-2025-30156/) (authentification CephX contournable via mauvais usage d'AES-CBC), Ceph a introduit un nouveau type de clé, `aes256k` (`AES256-CTS-HMAC-SHA384-192`, RFC 8009), qui remplace l'ancien cipher `aes`. Proxmox fournit un outil de migration (`pve-cephx-rotate-service-keys`, voir `man pveceph`) pour effectuer la rotation en douceur (double-clé pendant la transition, confirmation explicite avant de retirer l'ancien cipher).

Le cluster Ceph (8 hôtes pve01-08, `20.2.4-pve4 tentacle`) est déjà aligné et prêt côté serveur — les vérifications `AUTH_INSECURE_SERVICE_KEY_TYPE`/`AUTH_INSECURE_SERVICE_TICKETS` (sévérité erreur) sont déjà propres.

## Ce qui reste à migrer côté clients

`ceph health detail` liste 15 entités encore sur l'ancien cipher `aes` :

- ✅ **`client.admin`** — géré par le helper Proxmox (`--rotate-admin-key`), safe à roter (outils PVE + storages `CephFS`/`RBD_Common`, tous userspace sur hôtes kernel 7.0.14-16-pve)
- ✅ **`client.radosgw.pve01-08`** (×8) — démons RGW userspace natifs sur les hôtes PVE, safe à roter manuellement (hors scope du helper, pas un "storage" Proxmox)
- ⏳ **`client.csi-cephfs-node`** et **`client.csi-rbd-node`** — utilisés par `rook-ceph.cephfs.csi.ceph.com-nodeplugin` / `rook-ceph.rbd.csi.ceph.com-nodeplugin` sur les nodes Talos de `k8s-shared`, qui font des montages **kernel** (CephFS kernel mount, krbd). **Nécessite Talos v1.13.10+ (voir mise à jour plus bas), pas encore déployé.**
- 🔍 `client.k8s` — user orphelin, aucun secret CSI actif ne le référence dans `k8s-shared`/`production-v2`/`poc` (vérifié), safe à roter/retirer, priorité basse
- 🔍 `client.csi-cephfs-provisioner` / `client.csi-rbd-provisioner` — côté contrôleur (`ceph-csi` v3.17.0), pas de mount kernel direct, probablement safe mais pas encore confirmé formellement

## ~~Le blocage réel : kernel Linux ≥7.0 requis~~ → Résolu par backport, voir commentaire ci-dessous

~~Le support du cipher `aes256k` côté **client kernel** (`libceph`, utilisé par `krbd` et les montages CephFS kernel) n'a été mergé dans le noyau Linux qu'à partir de la **version 7.0**.~~

**Mise à jour** : Sidero Labs a backporté le support `aes256k` vers leur branche kernel 6.18 ([siderolabs/pkgs#1660](https://github.com/siderolabs/pkgs/pull/1660)). Disponible depuis **Talos v1.12.12 / v1.13.10 / v1.14.0+**. Détails complets dans le commentaire de suivi ci-dessous.

**Décision** : on cible **v1.13.10** pour `k8s-shared` (v1.14.0 change la façon de générer les machine configs, trop récent pour l'instant).

**Pas d'urgence immédiate** : les clients non migrés continuent à s'authentifier avec leur ancienne clé `aes` tant que `--restrict-ciphers` n'est pas appliqué côté serveur — donc `csi-cephfs-node`/`csi-rbd-node` restent fonctionnels sans interruption pendant la migration.

## Action

1. Migrer `client.admin` + `client.radosgw.pve01-08` dès que possible (non bloqué).
2. Bumper Talos `k8s-shared` de v1.13.7 → **v1.13.10** (kernel 6.18.48, support aes256k).
3. Migrer `client.csi-cephfs-node`/`client.csi-rbd-node` une fois le bump confirmé.
4. **Ne pas** lancer l'étape finale `--restrict-ciphers` avant que ces deux clients soient migrés — ça couperait les montages CephFS/RBD des pods.

## Références
- [CVE-2025-30156 — Ceph docs](https://docs.ceph.com/en/latest/security/CVE-2025-30156/)
- [Ceph in Linux 7.0 lands support for AES256K keys — Phoronix](https://www.phoronix.com/news/Ceph-Linux-7.0)
- [siderolabs/pkgs#1660 — backport aes256k support](https://github.com/siderolabs/pkgs/pull/1660)
- [Talos releases](https://github.com/siderolabs/talos/releases)
- Template Omni versionné : `AnsibleInfra/playbooks/omni/templates/k8s-shared-cluster.yaml`

Start with AnsibleInfra/playbooks/omni/templates/k8s-shared-cluster.yaml and verify how the k8s-shared Talos version is defined and deployed. Review the Talos v1.13.10 release details and the referenced backport before changing the version. Done means the cluster is upgraded, the CSI node clients support aes256k and are migrated, while cipher restriction remains deferred until both mounts are confirmed healthy.

Written by the indexing model from the issue text.