Коллеги, всем привет, меня зовут Алексей и это продолжение предыдущей статьи о проблемах с Ceph, возникших после обновления.

Коротко напомню, прошлый раз, я столкнулся с проблемой добавления в кластер Ceph, нового монитора, последней версии и OSD. Как мне казалось тогда, проблема была с пакетами Ceph для Ubuntu 24.04, которые собирают разработчики Ceph, но все оказалось намного сложнее и интереснее. К решению меня подтолкнул наш коллега по habr, который оставил свой комментарий к предыдущей статье. Он дал наводку, что возможно это связано с Cephx и обновлением ключей. Он же и сподвиг меня к написанию продолжения. Надеюсь эта статья принесет пользу и может быть кому‑то поможет. Итак, поехали.

Прочитав документацию по Cephx, я обнаружил, что разработчики рекомендуют после обновления кластера до последней версии провести так же и обновление ключей, используемых для аутентификации и авторизации в Ceph.

Cephx — это протокол аутентификации, имеющий дизайн как у Kerberos. Раньше для ключей использовался тип шифрования, который назывался — aes. Согласно документации, это старая 16-байтная структура, закодированная base64. Но самое главное она подвержена уязвимости согласно — CVE-2025-30156. По рекомендации разработчиков, для устранения уязвимостей, необходимо обновить Ceph до последних актуальных версий, которые поддерживают новый тип ключа — aes256k. Это 32-байтная расширенная структура. И поддержка такого типа ключей появилась в самых свежих версиях — 19.2.6(squid) и 20.2.4(tentacle).

Все вроде бы хорошо, берешь документацию, читаешь и вперед обновляться. Надо сказать отдельно, что если кластер развернут Cephadm или Rook, то ротация ключей выполняется при обновлении, без участия пользователя, но только для сервисных учетных записей, ротацию ключей клиентов необходимо выполнять вручную. Но как обычно дьявол кроется в деталях.

Почему‑то, разработчики не указали, что если у тебя например кластер уже собранный на одной из последних мажорных версиях, скажем — 20.2.0 которая присутствует в репозитории Ubuntu, то они не совместимы между собой. Например, в моем случае, у меня был кластер с тремя мониторами, Ubuntu 24.04 — 20.2.0, Alma Linux 9.5 — 20.2.0, Ubuntu 26.04 — 20.2.0. В текущих версия Ceph, произвести ротацию ключей с типом aes256k возможности нет, так как сам пакет Ceph не поддерживает его и у него даже нет тех опций, что указаны в документации. Идем дальше, пробуем обновить тогда текущие версии Ceph на последние, для которых указана поддержка новой типа ключей — 20.2.4.

После обновления Ubuntu 24.04, Alma Linux 9 до версий — 20.2.4, действительно появились опции для ротации ключей, с указанием типа ключа и возможность получения дампа ключей, где можно посмотреть его тип. И даже в дампе карты мониторов появились новые опции:

ceph mon dump

auth_service_cipher aes
auth_allowed_ciphers aes, aes256k
auth_preferred_cipher aes

Они как раз отвечают за настройку, какие типы ключей разрешено использовать для аутентификации в кластере.

  • auth_service_cipher — указывает какой тип ключей используется при ротации тикетов между службами Ceph.

  • auth_allowed_ciphers — указывает какие ключи разрешены для аутентификации в кластере, относится больше к клиентской части

  • auth_preferred_cipher — указывает предпочтительный тип ключа при создании новых ключей в кластере.

Так, но как же теперь поживает наш монитор на Ubuntu 26.04, ведь для этой ОС в репозитории ceph, нет собранных пакетов, а в репозитории ubuntu последняя версия — 20.2.0. А он просто выпадает из кластера и не может к нему больше присоединиться. Получается, если у вас кластер построен на этой версии Ubuntu, то вы не сможете обновиться или например заменить монитор в кластере. Ну и бог с ним, раз вы взяли этот дистрибутив, то вы сам себе злобный Буратино, как говорится))

Итог, проблема с кластером решена, берем, нормальные дистрибутивы, для которых у Ceph есть собранные пакеты и будет нам счастье.

И правда ротация ключей, согласно документации для сервисов Ceph, прошла без проблем. Я обновил ключи для mon, mgr, mds и osd, и все работает как часы. Казалось бы, а зачем нам эта статья, просто ради того, что бы сказать в документации все правильно написано? А вот тут мы дошли до самого интересного. Клиентские ключи.

Ради эксперимента, сделаем новые ключи для клиентов с указанием нового типа ключа и протестируем, как они будут работать с ними и вообще совместимы ли они.

1. Хранилище RBD для Proxmox:

Был развернут тестовый сервер PVE 9.2.2. Далее добавлен репозиторий ceph‑tentacle и установлен пакет ceph‑common=20.2.4.

Если использовать ключ созданный с указанием типа — aes. То добавление хранилища проходит без проблем.

pvesm add rbd test-rbd --monhost "10.10.10.101,10.10.10.102,10.10.103"     --pool test-rbd --content images --username admin    --keyring /root/ceph.client.admin.keyring

Теперь создаем точно такой же ключ, с теми же правами, но с типом — aes256k.

Пробуем добавить хранилище тем же способом и видим в логах ошибку:

Not a proper rbd authentication file: /etc/pve/priv/ceph/test-rbd.keyring

Проблема скорее всего возникает, потому как 9.2.2 хоть и актуальная версия Proxmox, но для подключения хранилища используется модуль ядра, а их обновление явно занимает больше времени, чем обновление приложений. Так что скорее всего это временная проблема и она будет решена. Получается, если вы используете Ceph хранилище в связке с Proxmox, то пока, что стоит оставить клиентские ключи со старым типом — aes.

2. Простое подключение образов через модуль ядра libceph:

rbd map --id admin256 --keyring /etc/ceph/ceph.client.admin256.keyring kube/test.img

Получаем ошибку в dmesg:

[Fri Sep 11 09:18:31 2026] libceph: secret too big 32

Модуль ядра libceph не поддерживает ключ такой длины. Ubuntu 24.04 — ядро — 6.8.0–139-generic

Astra Linux 10.2 ядро — ядро 6.12.0–211.50.1.el10_2.x86_64. Модуль ядра работает, он поддерживает новый тип ключей.

Вывод, если вы используете последние актуальные ядра Линукс, то можно смело производить ротацию и закрывать уязвимость, если же нет, то стоит повременить.

3. Ceph‑csi‑operator K8S:

Буквально в момент написания статьи вышла новая версия — v1.0.5 (от 11.09.2026) и в ней теперь появилась поддержка нового типа ключей. Когда начинал тесты, была версия v1.0.4 и там еще ничего не работало. Но все равно, так как ceph‑csi‑operator использует модули ядра на рабочих Нодах K8S для монтирования CephFS или RBD в контейнеры, то создать новый PV через оператора вы можете, но при старте контейнеров в поде, получите ошибку при монтировании:

stderr: adding ceph secret key to kernel failed: Unknown error 524
couldn't append secret option: -524

Получается либо необходимо обновлять ядро на рабочих Нодах K8S кластера, либо оставлять ключи старого формата для оператора.

4. FUSE

Проверка проводилась с использованием родной для Ceph утилиты ceph‑fuse. Это реализация клиента FUSE для ceph.

Как и предполагалось, самая актуальная версия 20.2.4 поддерживает работу с ключами типа — aes256k. А версия более старая — 20.2.0 — не поддерживает. Тут в принципе все комментарии излишни, обновить пользовательскую программу проблем возникнуть не должно, если только у вас не Ubuntu 26.04)).

Итог

Получаем следующую картину, что если мы имеем кластер в котором версии мониторов не поддерживают новый тип ключей, то при потере одной из Нод, полностью, скажем переустановка ОС. Мы не сможем вернуть ее в кластер, так как в репозитории Ceph, уже нет старых пакетов без поддержки — aes256k. Значит, нам необходимо будет полностью провести обновление всех Нод кластера.

После обновления, можно производить ротацию всех служебных ключей, если вы обновили так же все элементы кластера. Так как скажем, если у вас есть старые OSD демоны, то вы не сможете добавить новый OSD в кластер после ротации ключа — bootstrap‑osd.

С клиентами, все намного сложнее. Не все клиенты, особенно те, что завязаны на использование модулей ядра, для работы с Ceph, поддерживают новый тип ключей. Но слава богу, разработчики Ceph предоставили возможность оставить поддержку старых ключей. При этом конечно остается уязвимость, которую скажем, RedHat предлагает минимизировать, путем изоляции сети Ceph от возможных злоумышленников.

Еще одна неприятная вещь, это предупреждения уровня — WARN и ERR в выводе команд о статусе кластера.

ceph health detail
ceph -s

Но их можно на время убрать, например:

ceph health mute AUTH_INSECURE_SERVICE_KEY_TYPE 2w

На этом все, очень надеюсь, что данная статья будет кому‑то полезна.