There are some hints for that in
https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pveceph_cephx_how_it_works section, but we did not want to blow the docs up completely.
But roughly, active ceph sessions authenticated with the a ceph monitor and got a monitor ticket from that. This monitor ticket has a (default) TTL of 3 days (but if a monitors old key gets wiped it will expire immediately) and can be used to get ceph service ticket, which are then then used to authenticated with the OSD or MDS (which asks the monitor if its valid) for actual ceph IO. The service ticket has a (default) TTL of 1h.
Upstream ceph has a primitve form of staging a new client key, but that key will be automatically activated once its used, making the old keys obsolete - this was adapted in the Proxmox ceph packages to be more graceful (and we're in the process of upstreaming it, but need to do some upfront work at upstream to make it acceptable there). So, with an external non-Proxmox Ceph setup that has upstream behavior it's likely that once you start the process of changing the client key and moved the first service over, you also started clock for all other services, as their ticket might not get renewed after the TTLs expire.
For PVE you would switch the storage to the new client key, and then to move services over to use it. For VMs its enough to live-migrate them or alternatively restart them, CephFS needs to be remounted and containers on RBD restarted, there is no possibiliity to teach a running librbd or the like of a new client key to allow using either. But this is a code path we did not tested as extensively, or at least not I in such a way that I got all the info correctly available from top of my head, so please test this and read up yourself before doing anything.
