Hi Jan, On Thu, Aug 20, 2026 at 10:54 AM Jan Kasprzak <ceph-users@ceph.io> wrote:
Hi all,
Patrick Donnelly wrote:
Today, August 19th, 2026, the Ceph project has released Tentacle 20.2.4 and Squid 19.2.6 hotfixes for four CVEs across several components.
I have just upgraded one of my cluster from 20.2.3 to 20.2.4. The documentation seems to be clear (thanks!) and worked for me with the exception of step 4:
4. Confirm the AUTH_INSECURE_SERVICE_KEY_TYPE is cleared.
ceph --format=json health detail | jq '.checks | has("AUTH_INSECURE_SERVICE_KEY_TYPE") | not'
output gives false.
If it outputs true, there is another daemon that needs to be upgraded. Check the output of ceph health detail.
I might have done something wrong, but if I remember it correctly, at this point I still got 4 AUTH_INSECURE_SERVICE_KEY_TYPE keys, and had to do step 5 "ceph mon set auth_service_cipher aes256k" first and then step 6 "ceph auth wipe-rotating-service-keys". Only then the AUTH_INSECURE_SERVICE_KEY_TYPE disappeared from ceph health detail (together with AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE).
AUTH_INSECURE_SERVICE_KEY_TYPE indicates that the service, e.g. osd.0, is using an aes key to authenticate with the Monitors. That can only be addressed by rotating that service's key. The other health error is AUTH_INSECURE_ROTATING_SERVICE_KEY_TYPE which is addressed by the auth_service_cipher monitor setting (required) and wiping the rotating key database (optional).
One question, though: is it possible to have a client with two keys, aes and aes256? One of my cluster is mainly used for RBD with client.libvirt user, and I have hundreds of running VMs, which I cannot restart at once. So I would like to _add_ an aes256 key to the client.libvirt user, and incrementally restart the qemu processes which use this secret.
No, you cannot have two keys. I think a lesson (for everyone) here is that each node should have its own client key. It became prevalent to use the same key everywhere for simplicity but it makes deployments and updates more challenging.
Or what is the recommended way of gradually replacing a client key?
Create new keys for each node. -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D