Ceph canvia de xifratge: reiniciar la màquina virtual no refresca la clau

La frase més important de la migració de claus de Ceph que Proxmox va publicar el 9 de setembre no és a l'anunci. És enterrada a la documentació, a la llista de com refrescar els clients, i són sis paraules: «A guest reboot is not enough». Reiniciar la màquina virtual no val. Cal migrar-la en viu o aturar-la i arrencar-la. I si no ho fas bé, no te n'assabentes aquell dia: te n'assabentes quan caduqui el tiquet, que poden ser minuts o poden ser dies.

Operem Proxmox VE amb emmagatzematge Ceph en producció, així que això ens toca a nosaltres i a la majoria de clústers que mantenim. El 9 de setembre a les 02:39, al fòrum oficial, Proxmox va obrir el fil «Cephx Key Migration Procedure and Ceph 19.2 Squid Going EOL Soon» i amb ell un procediment que no és opcional i que no s'assembla a un apt upgrade. Aquest article va de què és exactament, què ha canviat des d'agost, on és el parany i en quin ordre ho fem.

El teu clúster es va posar en vermell tot sol

L'origen és d'agost. El 19 d'agost Ceph va publicar alhora 20.2.4 i 19.2.6 per tancar quatre CVE, i un d'ells —CVE-2025-30156, un bypass d'autenticació a cephx per mal ús d'AES-CBC— no s'arregla instal·lant el paquet. Cal canviar el tipus de les claus. Ho vam explicar aleshores a l'anàlisi d'aquells quatre CVE, on ja vam dir que n'hi havia un que el paquet no tanca tot sol. Això és la segona meitat d'allò.

Ho descriu Proxmox sense embuts: «Recent security findings and fixes in Ceph make it necessary to upgrade ceph and migrate authentication keys from the aes to the aes256k cipher», i hi afegeix el matís que decideix la prioritat: «especially if your Ceph service networks are not isolated». Si la teva xarxa de servei de Ceph està separada de debò, respires una mica. Si comparteix switch amb la resta, no.

El primer que nota la gent és que el clúster es posa en HEALTH_ERR sense haver tocat res. No és una fallada. 19.2.6 i 20.2.4 porten comprovacions de salut noves sobre el xifratge de les claus —la taula de referència de la documentació en llista sis— i dues d'elles —AUTH_INSECURE_SERVICE_KEY_TYPE i AUTH_INSECURE_SERVICE_TICKETS— són de severitat error. La documentació ho aclareix: «This does not mean that storage access or a Ceph service has failed». L'emmagatzematge continua funcionant; el que ha canviat és el que el semàfor mesura.

Què ha canviat des d'agost: ara hi ha xarxa

A l'agost, rotar les claus cephx a mà eren deu passos i un clúster en vermell mentre durés. Això és el que Proxmox ha canviat, i cal reconèixer-ho: han posat un script de migració —/usr/share/pve-manager/migrations/pve-cephx-rotate-service-keys— i, sobretot, han millorat el mecanisme de claus en espera de Ceph perquè el relleu sigui gradual: «both keys remain valid while you refresh clients, including running guests and CephFS mounts, to use the new key».

Aquest període de gràcia és el que de debò aporta el procediment nou, i té requisits concrets que convé comprovar abans de començar: pve-manager 9.2.17 o superior, i per a la rotació esglaonada de claus de client, Ceph 19.2.6-pve3, 20.2.4-pve3 o posterior a tots els monitors. La raó: un monitor antic promociona la clau pendent així que algú la fa servir per primera vegada, i amb això s'acaba el període de gràcia per a tot el clúster. Per això l'script comprova a cada execució que tots els monitors admeten la funció, i es nega a deixar la clau nova en espera si algun no ho fa.

El rellotge d'aquesta avaria no el poses tu

L'avís de Proxmox: si retires la clau vella o restringeixes els xifratges abans que tots els clients estiguin refrescats, «incompatible or not-yet-refreshed clients may see I/O failures on reconnecting or when existing service tickets expire, which can be minutes or days after the change». I: «Existing IO can appear to work until a reconnect and then fail».

Traduït a la vida real: executes l'ordre a les 23:00 del dissabte, mires el clúster, tot verd, totes les VM escrivint, te'n vas a dormir. El dimarts a mig matí una màquina que ningú no ha tocat perd el disc. No és que el canvi fallés tard; és que el canvi mai no falla en el moment en què es fa. La finestra de manteniment la fixes tu i l'avaria la fixa el venciment d'un tiquet de servei. Són dos rellotges diferents, i el segon no és al teu calendari.

D'aquí la regla de la documentació: «Do not use --force to bypass a blocker». Un bloqueig pot ser una sessió que encara porta la clau antiga, però també una verificació de versió que no quadra o claus de dimonis que ja no existeixen; al mateix fil hi ha exemples de les tres coses. Saltar-se'l no accelera la migració, mou la fallada a un dia en què ja no estaràs mirant.

Què compta com a «refrescar un client»

Abans de refrescar res cal saber quin tipus de client té cada càrrega, perquè d'això depèn si et serveix la biblioteca d'espai d'usuari que ja has actualitzat amb el paquet o si depens del kernel de la màquina. La documentació ho resumeix en tres línies:

• Màquina virtual amb discos RBD: espai d'usuari, llevat que tinguis krbd activat.
• Contenidor sobre RBD: sempre client de kernel. Sempre. No hi ha variant.
• Muntatge CephFS: kernel, llevat que facis servir fuse.

Per refrescar una VM afectada, la instrucció és migrar-la en viu des de la interfície web, o aturar-la i arrencar-la. I al darrere: «A guest reboot is not enough». Té tota la lògica quan hi penses —el procés QEMU de l'amfitrió és el que sosté la connexió amb Ceph, i reiniciar el sistema operatiu de dins no el toca—, però és exactament el contrari del que fa l'instint de qualsevol a qui li diuen «reinicia els clients». Si algú del teu equip fa la ronda de reinicis des de dins de les VM i et diu que ja està, no està.

Els contenidors i la resta de clients RBD s'aturen i s'arrenquen. Els muntatges CephFS els refresca el mateix script si estan ociosos, i deixa en pau els que estiguin ocupats o no responguin: quan ningú no els faci servir, es torna a executar amb --apply i es reintenten. I hi ha un detall que a nosaltres ens sembla el més fàcil d'oblidar en un clúster amb feina nocturna: les còpies, les restauracions, les importacions de disc i els clons sobre emmagatzematge Ceph poden conservar la clau amb què van començar. Cal deixar-los acabar abans de confirmar. Un backup llarg que va arrencar a les dues de la matinada és un client amb clau vella encara que a la interfície no ho sembli.

La porta que decideix si pots acabar: kernel 7.0

Els programes de Ceph dels paquets actualitzats de Proxmox VE admeten aes256k. Els clients de kernel, no tots: cal kernel 7.0 o superior en execució. I aquesta frase, que al fil passa com un requisit tècnic més, és en realitat la que decideix si el teu clúster pot tancar la migració aquest mes o no.

Convé llegir el requisit amb cura, perquè diu kernel en execució, no versió de Proxmox VE. Fem el compte amb les versions reals: Proxmox VE 9.2, publicat el 21 de maig de 2026, porta el 7.0 com a kernel per defecte; Proxmox VE 9.1 anava amb el 6.17 i 9.0 amb el 6.14; i Proxmox VE 8 fa servir el 6.8 des de la 8.2, amb el 6.14 disponible com a opció des de la 8.4. Ara bé, a tota la sèrie 9 el 7.0 està disponible com a opt-in des del 2 d'abril —apt install proxmox-kernel-7.0 i reiniciar—, de manera que un node a la 9.1 pot complir el requisit sense canviar de versió major. La comprovació no és «a quina versió de Proxmox soc?», és uname -r a cada node que allotgi clients de kernel, i cal fer-la node a node: en un clúster que s'ha anat actualitzant per parts, hi conviuen kernels diferents amb tota naturalitat.

Per a qui continuï a Proxmox VE 8 la cadena es tanca sola i no és agradable: la branca 8 va deixar de rebre suport a l'agost, no té kernel 7.0, i per tant no pot completar l'últim pas d'aquesta migració encara que instal·li tota la resta. El correcte en aquest cas és el que diu la documentació: deixar la clau d'aquell usuari sense tocar i el xifratge antic habilitat, i silenciar l'avís mentrestant. No restringir. Restringir amb un client incompatible per allà és exactament l'escenari de l'apartat anterior.

El que ja està passant al fil

Sis dies després de l'anunci, el fil continua viu i dona per a un retrat força honest de com va això. Hi ha qui ho ha fet sense incidents en un clúster de tres nodes i explica que la part incòmoda va ser no saber quan continuar, perquè molts passos no imprimeixen un verd clar de «això ha anat bé». Hi ha qui demana que el procediment surti de la documentació general i tingui la seva pròpia guia, amb l'argument que és una migració d'una sola vegada i arriscada, i no una tasca del dia a dia. Ens semblen dues queixes raonables.

I hi ha, ja, gent amb el clúster a mitges. Dos usuaris han publicat el mateix missatge després d'executar la rotació, Not a proper rbd authentication file:, cadascun sobre un fitxer de claus diferent —CEPH00.keyring en un cas i ceph.keyring en l'altre—, i un d'ells amb una màquina virtual que ja no arrenca després d'apagar-la; explica que l'origen va ser un copiar-i-enganxar que va barrejar opcions de dos passos diferents. Dos més s'han quedat bloquejats a la comprovació prèvia: a l'un li falla perquè un dels seus monitors viu en una màquina que Proxmox no gestiona i l'script no li pot verificar la versió; a l'altre, perquè el clúster encara reclama claus insegures de dos gestors que ja no existeixen.

No ho expliquem per assenyalar ningú: ho expliquem perquè els tres casos diuen el mateix. El risc d'aquest canvi no és a la criptografia, que és la part que ja està resolta i provada. És a l'inventari: saber quins clients tens, quins no gestiona Proxmox, quins guarden una còpia de la clau en un fitxer seu i quins fa setmanes que no es reconnecten. Això no ho sap l'script. Ho diu ell mateix quan llista les sessions sospitoses: són pistes, no un inventari complet.

L'ordre que seguim nosaltres

No és un procediment alternatiu a l'oficial —l'oficial està bé i cal seguir-lo—, sinó l'ordre en què l'encaixem nosaltres perquè la part d'inventari no quedi per al final:

1. L'inventari, abans que cap ordre. És el mateix primer punt que ja vam posar a l'agost, i el que el procediment nou hi afegeix és que ara l'inventari decideix també a qui pots confirmar i a qui no. Quins usuaris de Ceph existeixen, quina càrrega fa servir cadascun, quins són clients de kernel, què hi ha fora de Proxmox i on està copiada cada clau. Això es fa en un full de càlcul i és la part que decideix si la migració surt bé.
2. Versions i kernel. pve-manager 9.2.17 o superior, Ceph amb sufix -pve3 o posterior a tots els monitors, i kernel en execució 7.0 o superior a cada node que allotgi clients de kernel.
3. Primer les claus del clúster (--rotate-cluster-keys). És el pas segur: no toca les claus d'emmagatzematge ni client.admin, els tiquets existents continuen valent i el xifratge antic continua habilitat. Amb això es netegen les dues comprovacions de severitat error.
4. Paciència amb l'avís que queda. El de les claus rotatives de servei pot trigar unes hores a desaparèixer i se'n va tot sol. No bloqueja la restricció final, així que no cal esperar-lo per continuar, però convé saber-ho abans de començar a dubtar.
5. Preparar la clau nova i refrescar, usuari a usuari. Migració en viu o aturar-arrencar; mai reinici del convidat. Deixar acabar còpies i clons.
6. Comprovar amb l'eina correcta. pveceph auth status mostra els xifratges actuals i els pendents; ceph auth ls no llista les claus pendents, així que mirant-hi es veu un clúster més net del que està.
7. Confirmar només al final, i només si l'inventari està tancat. Si queda un client incompatible, es deixa la seva clau i el xifratge antic, i se silencia l'avís. Un avís silenciat amb data de revisió és millor gestió del risc que una restricció que tomba un contenidor el dimarts.
8. I no esborris el diari. /etc/pve/priv/cephx-key-migration.json guarda el progrés i conté les claus antigues en clar: es protegeix, i es conserva fins que la migració estigui completa. Si l'esborres abans, perds el que cal per reprendre-la.

Val la pena saber que hi ha marxa enrere i que hi ha sortida d'emergència, perquè saber-ho canvia com s'aborda el pas arriscat. Una clau nova que està en espera es pot avortar amb --abort-staged-key, que retorna la clau actual a totes les còpies gestionades mentre les dues continuen valent. Però no és una ordre, en són tres: avortar, refrescar els clients de tornada —inclosos els desconnectats i les còpies externes— i confirmar amb --confirm-abort-clients-refreshed; i si els teus monitors no són a 19.2.6-pve4 o 20.2.4-pve4, que són els que saben identificar la clau de cada sessió, tots els clients visibles d'aquell usuari s'han de desconnectar abans de confirmar. La marxa enrere costa gairebé tant com l'anada. I si algú es passa de frenada i restringeix els xifratges deixant-se fora la clau d'administració, hi ha l'opció d'arrencada mon_auth_emergency_allowed_ciphers, que substitueix la llista permesa en un monitor per recuperar l'accés. Serveix per recuperar l'accés i res més: mentre estigui posat, Ceph aixeca AUTH_EMERGENCY_CIPHERS_SET i l'script es nega a fer la restricció final.

Dues migracions al mateix trimestre

El calendari és el que converteix això en una decisió de direcció i no només en una tasca de sistemes. Els paquets van arribar fa poc als repositoris sense subscripció, després d'un període llarg de proves internes, i Proxmox va escriure el 9 de setembre que planejava treure'ls als repositoris enterprise «in the second half of next week», avisant que es podia endarrerir uns dies segons el control de qualitat i la resposta del fil. Aquella setmana que ve és aquesta. Si els teus clústers són a enterprise, l'actualització que encén les comprovacions noves et pot arribar en qüestió de dies, i amb ella el HEALTH_ERR.

I no ve sola. El mateix avís recorda que Ceph 19.2 Squid té data estimada de fi de vida el 31 d'octubre de 2026, amb la recomanació de pujar a Tentacle mentre Squid continuï suportat —i això exigeix Proxmox VE 9.2 o superior, amb la qual cosa qui sigui a la 8 té una altra migració al davant primer. D'on surt aquesta data i per què la tractem com una estimació i no com una garantia ho expliquem a l'article sobre el commit que la va moure.

La nostra opinió, que és opinió i no dada, i que a més no és nova —la vam escriure a l'agost, amb aquestes paraules: «no estrenar Tentacle alhora»—: no les apilis. La rotació de claus i el salt de Squid a Tentacle són dos canvis que toquen el mateix i fallen diferent, i ajuntar-los a la mateixa finestra estalvia una nit i complica el diagnòstic de la setmana següent. Si alguna cosa es trenca el dijous, vols poder dir què va canviar el dissabte sense haver de triar entre dos candidats. Nosaltres fem primer la rotació, la deixem assentar uns dies amb el xifratge antic encara habilitat, i només aleshores toquem versions.

En aquest canvi, la comprovació que ha sortit bé no és que el clúster estigui verd. És que cap client continuï amb la clau vella. Són dues preguntes diferents, i només la segona la contesta l'inventari que vas fer abans de començar.

Nota de fonts

L'anunci i les citacions entre cometes sobre el procediment, el kernel 7.0, els clients externs i el calendari del repositori enterprise són del fil «Cephx Key Migration Procedure and Ceph 19.2 Squid Going EOL Soon» del fòrum oficial de Proxmox, publicat per un membre de l'equip el 9 de setembre de 2026 a les 02:39 (hora del fòrum). Els passos, els noms de les sis comprovacions de salut, els requisits de versió, la taula de tipus de client, la frase «A guest reboot is not enough», l'avís sobre --force, el fitxer cephx-key-migration.json, pveceph auth status, --abort-staged-key i mon_auth_emergency_allowed_ciphers són a la secció «Migrate Cephx Keys from aes to aes256k» de la documentació de referència de Proxmox VE (pve-docs, capítol pveceph). L'atribució de CVE-2025-30156 al mètode antic és d'aquesta mateixa secció; els quatre CVE i les versions 19.2.6 i 20.2.4 són de l'avís combinat de Ceph del 19 d'agost de 2026. Les versions de kernel per branca de Proxmox VE surten del wiki Proxmox VE Kernel; que el 7.0 sigui el predeterminat a la 9.2, de l'anunci oficial de Proxmox VE 9.2 del 21 de maig de 2026; i que estigui disponible com a opt-in a tota la sèrie 9, del fil «Opt-in Linux 7.0 Kernel for Proxmox VE 9 available» del 2 d'abril de 2026, d'on surt també l'ordre d'instal·lació. Els casos d'usuaris i el missatge d'error citat són missatges públics del mateix fil, consultats el 15 de setembre de 2026; no els hem reproduït amb noms. La data estimada de fi de vida de Squid (31 d'octubre de 2026) és la que dona el mateix avís de Proxmox. El que aquí és opinió nostra —no apilar les dues migracions, l'ordre de treball i que el risc és a l'inventari— va dit com a tal al text.