Миграция ключей аутентификации Ceph на aes256k без потери доступа к кластеру
Поэтапная ротация сервисных и клиентских ключей Ceph с сохранением кворума, административного доступа и контролируемого отката.
Проверено на: Proxmox VE 9.x · Ceph cluster
Контекст
Кластер Ceph может оставаться работоспособным и при этом продолжать разрешать или использовать типы ключей аутентификации, которые уже не соответствуют принятому уровню безопасности.
Ротация таких ключей — не одно переключение. В аутентификации участвуют monitors, managers, OSD и административные клиенты. Неполная миграция может либо заблокировать доступ администраторов, либо нарушить взаимодействие между демонами.
Безопасный подход — сначала поэтапно заменить ключи, а уже затем отдельно ужесточать политику monitors.
До изменения ключей
Сначала подтвердите состояние кластера и пути восстановления.
- проверьте monitor quorum;
- зафиксируйте текущий health state и существующие warnings;
- убедитесь, что административный доступ работает более чем с одного ожидаемого узла;
- не совмещайте ротацию ключей с обновлениями и другими работами со storage;
- при необходимости перенесите некритичные workload, если это снижает риск.
Цель не в том, чтобы любой ценой получить идеально чистый HEALTH_OK. Важно иметь исходную точку, чтобы новые проблемы можно было связать именно с изменением аутентификации.
Порядок ротации
Ротируйте сервисные identities контролируемыми группами, а не заменяйте все ключи одновременно.
После каждой группы проверяйте:
- соответствующие демоны снова подключились;
- quorum остаётся стабильным;
- placement groups не перешли в неожиданный state;
- административный доступ сохраняется.
Ключ client.admin требует отдельной осторожности. Меняйте его только когда уже существует другой заведомо рабочий административный путь, и обязательно проверьте новый ключ до отключения старого.
Не ужесточайте политику monitors слишком рано
Разделяйте два состояния:
- все известные сервисные и клиентские ключи уже переведены на более сильный тип;
- monitors полностью запрещают старые небезопасные типы ключей.
Сначала завершите первый этап и проверьте активные сессии. Только после этого переходите ко второму.
Если monitor-side restriction включить, пока забытый daemon или client ещё использует старый тип ключа, обычная security-миграция легко превратится в availability incident.
Проверка
После каждого этапа проверяйте:
- monitor quorum и доступность manager;
- общий Ceph health и состояние placement groups;
- подключение OSD;
- аутентификацию с ожидаемых административных узлов;
- тип ключа у каждой уже ротированной service identity;
- активные monitor sessions перед финальным ужесточением политики.
Если сервисные ключи уже соответствуют требуемому уровню, но monitors временно всё ещё разрешают старые типы, оставляйте соответствующий warning явным. Это означает незавершённый enforcement, а не неудачную ротацию.
Эксплуатационный вывод
Для clustered infrastructure полезно разделять замену credentials и ужесточение политики.
Сначала доказывается совместимость новых ключей. Затем старый fallback отключается только после того, как фактическое состояние показывает, что он больше не нужен.