Neu in Ceph

CephX verschlüsselte Tickets bisher mit AES-128-CBC ohne HMAC und mit festem IV. Mit einem einzigen niedrig privilegierten Key ließen sich per Bit-Flip Tickets mit Admin-Rechten für OSD, MDS und MGR fälschen. Dieselbe Ursache steckt in den STS-Session-Tokens des RGW (CVE-2026-39944, relevant bei rgw_s3_auth_use_sts = true), der Fix kommt in denselben Releases. Neu ist der Key-Typ aes256k (AES256-CTS-HMAC-SHA384-192 nach RFC 8009). Nach dem Upgrade melden sechs neue Health-Checks AUTH_INSECURE_*, teils als Fehler. Sie verschwinden schrittweise: auth_preferred_cipher und auth_service_cipher per ceph mon set auf aes256k, Keys mit ceph auth rotate --key-type=aes256k rotieren, zuletzt auth_allowed_ciphers auf aes256k. Diesen letzten Schritt erst, wenn AUTH_INSECURE_SERVICE_KEY_TYPE und AUTH_INSECURE_CLIENT_KEY_TYPE weg sind, sonst hilft nur noch der Notfallweg über mon_auth_emergency_allowed_ciphers. cephadm rotiert die Daemon-Keys selbst, das Upgrade dauert dadurch länger als gewohnt. Client-Keys rotiert es nicht.

Für den Kernfix reichen das Daemon-Upgrade und die Rotation der Keys von mon, mgr, osd und mds. Danach bekommen auch Clients mit alten aes-Keys Service-Tickets mit aes256k. Client- und Kernel-Updates empfiehlt Ceph, verlangt sie aber nicht. Der Kernel-Client (krbd, CephFS-Kernelmount, damit auch Ceph-CSI) versteht aes256k erst ab Linux 7.0, mit FIPS-Enforcing ab 7.2, Backports gibt es für CentOS Stream 9 und 10. Rook rät zu v1.20.6 oder v1.19.10 und rotiert erst, wenn spec.security.cephx.daemon auf keyRotationPolicy: KeyGeneration mit höherer keyGeneration steht. CSI-Keys behalten keyType: aes, bis alle Nodes Kernel 7.0 fahren, der RBD-Mirror-Peer-Key (spec.security.cephx.rbdMirrorPeer), bis alle Peer-Cluster aes256k können. Die Per-Export-Keys von NFS-Ganesha lassen sich noch nicht rotieren.

RGW prüfte bisher nur die Header aus X-Amz-SignedHeaders. Wer eine presigned PUT-URL besaß, konnte beliebige x-amz-*-Header anhängen, etwa x-amz-copy-source mit public-read-ACL, und so jedes Objekt lesen, auf das der Signierer Zugriff hat. Jetzt lehnt RGW Requests mit unsignierten host- oder x-amz-*-Headern ab. Der REST-Client der Multisite-Synchronisation erzeugt genau solche Requests: vor dem Upgrade rgw_sigv4_insecure=true setzen und erst nach dem Upgrade aller Cluster wieder auf false stellen.

Jede CephX-Identität mit mon 'allow r' konnte mit einer einzigen MMonSubscribe-Nachricht den kompletten Config-Key-Store des Monitors lesen, darunter OSD-LUKS-Passphrasen, Dashboard-Secrets und den SSH-Key, mit dem cephadm auf jeden Host kommt. Nach dem Upgrade den cephadm-SSH-Key rotieren. Ein offizielles Verfahren für die übrigen Secrets kündigt das Projekt an, es steht noch aus.

Eine neue Implementierung des EC-I/O-Pfads bringt partielle Reads und Writes sowie geringere Space Amplification. Der größte Effekt liegt bei RBD und CephFS, RGW profitiert vor allem bei kleinen Objekten. Aktiviert wird pro Pool über allow_ec_optimizations, sobald OSDs und Monitore aktualisiert sind. Clients müssen nicht angefasst werden.

Neu angelegte EC-Pools auf Clustern, die mit Tentacle oder später installiert wurden, nutzen ISA-L statt Jerasure, weil die Jerasure-Bibliothek nicht mehr gepflegt wird. Bestehende Cluster behalten beim Upgrade ihren bisherigen Default.

Das neue certmgr-Subsystem von cephadm arbeitet als cluster-interne Root-CA, nimmt alternativ eigene Zertifikate entgegen und protokolliert, woher jedes Zertifikat stammt. Es erneuert cephadm-signierte Zertifikate automatisch und wirft Health-Warnungen bei ungültigen oder ablaufenden Zertifikaten.

Ein cephadm-verwalteter NGINX-Reverse-Proxy terminiert TLS und fasst Dashboard, Prometheus, Grafana und Alertmanager hinter einem Endpunkt zusammen. Man muss nicht mehr wissen, auf welchem Host welcher Daemon läuft. Mit mehreren Instanzen und einer virtuellen IP bleibt der Zugang auch bei Daemon- oder Host-Ausfall erreichbar. Dazu passend bindet der neue oauth2-proxy externe Identity Provider für SSO an.

Das neue smb-Modul erzeugt Samba-basierte SMB-Shares auf CephFS, analog zum bestehenden NFS-Subsystem. Es beherrscht Active-Directory-Domänen und Standalone-Authentifizierung, kann mehrere virtuelle SMB-Cluster hosten und diese über Sambas CTDB echt clustern. Voraussetzung ist ein cephadm-Cluster.

Images lassen sich sofort aus einem anderen Ceph-Cluster importieren, über den neuen NBD-Stream auch aus beliebigen externen Quellen. Beim Mirroring müssen lokaler und entfernter Namespace nicht mehr identisch sein, die neue Option --remote-namespace koppelt beliebige Namespaces.

Zur Kompatibilität mit AWS S3 werden LastModified-Zeitstempel auf volle Sekunden gekürzt. Während des Upgrades können diese Zeitstempel dadurch rückwärts springen. Clients, die darauf Änderungserkennung oder Sortierung aufbauen, vorher prüfen.

Für alle Device-Typen ist msgr2 Default; wer krbd über msgr1 fahren muss, übergibt -o ms_mode=legacy. Die seit 2020 abgekündigten Module mgr/restful und mgr/zabbix sind raus, unter anderem wegen Schwachstellen in ihrer Abhängigkeitskette. Ersatz ist das dashboard-Modul mit seiner RESTful-API beziehungsweise das prometheus-Modul.

Wer eine Stretch-Konfiguration mit CRUSH-Regeln über mehrere take-Schritte fährt, muss beim Upgrade mit Datenumverteilung rechnen. Eine Stretch-Regel mit einem einzelnen take löst keine Bewegung aus. Zusätzlich meldet ceph df für solche Pools ein falsches MAX AVAIL, weil nur ein Rechenzentrum in die Berechnung eingeht.

Die in Squid eingeführten User Accounts sind der reguläre Weg für IAM-APIs und Policies. Die tenant-basierte Variante fällt frühestens im V-Release weg: CreateRole, PutRolePolicy und PutUserPolicy auf Tenant-Ebene, Tenant-Namen in Policy-Dokumenten, Cross-Tenant-Namen der Form Bucket=tenant:bucketname sowie STS Lite. Der Tenant selbst bleibt als Namespace-Isolation erhalten.

Ein neues NVMeoF-mgr-Modul legt den Metadaten-Pool ".nvmeof" selbst an, falls er fehlt, und speichert dort den Zustand der Gateway-Gruppen. Auf Neuinstallationen ist es automatisch aktiv, bei Upgrades bestehender Cluster muss es von Hand aktiviert werden. Das ist der Punkt, den man beim Upgrade sonst übersieht.

Die Beast-Frontend-Option ssl_ciphersuites macht die TLS-1.3-Cipher konfigurierbar. Kafka-Notifications unterstützen Client-Zertifikat-Authentifizierung per mTLS. Dazu kommt CopyObject für verschlüsselte Objekte.

Der globale Roles-Tab im Dashboard ist entfernt. Rollen werden jetzt im Kontext eines ausgewählten RGW-Accounts verwaltet. Wer den Weg dokumentiert oder eingelernt hat, muss ihn anpassen.

EC-Optimierungen lassen sich für nicht 4K-alignte Chunk-Größen nicht mehr aktivieren, solche Konfigurationen liefen schlecht und waren fehlerbehaftet. Wer allow_ec_optimizations auf einem Pool mit unpassender Chunk-Größe plant, muss das Profil anpassen.

Die Failover-Logik der Gateways ist neu gebaut, Beacon-Timeouts werden früher ausgewertet, die Erkennung langsamer Monitore ist verbessert. Passend dazu sinken die Defaults: mon_nvmeofgw_beacon_grace von 10 auf 7 Sekunden, nvmeof_mon_client_tick_period von 2 auf 1 Sekunde.

Umfangreiche Korrekturen an Linger-Operationen beseitigen Use-after-free-Zustände und Speicherlecks, wenn ein Unwatch ENOTCONN liefert. Relevant für alle, die eigene librados-Anwendungen mit Watch/Notify betreiben.

Die Debug-Option heißt jetzt bluefs_check_volume_selector_on_mount statt _on_umount und prüft beim Mount wie beim Unmount. Konfigurationen mit dem alten Namen greifen nicht mehr.