Современный мир облачных технологий постоянно требует надежных и автоматизированных инструментов для управления безопасностью, причем ключевым элементом инфраструктуры безопасности являются сертификаты. В этой сфере проекты cert-manager и trust-manager от Venafi стали эталонами автоматизации выпуска и ротации сертификатов в инфраструктурах, использующих TLS. Особенно важную роль они играют в экосистеме сервис-мешей, где правильное управление сертификатами влияет напрямую на безопасность и стабильность связи между сервисами. Linkerd, будучи одним из лидирующих сервис-мешей, широко применяет cert-manager и trust-manager для доступа к надежным механизмам выпуска, ротации и распространения сертификатов. Однако обновление cert-manager с версии 1.
17 до 1.18 принесло существенные изменения, способные вызвать серьезные проблемы в тех установках, где конфигурация trust-manager не соответствует новым требованиям. Понимание сути этих изменений и грамотный подход к обновлению крайне важны для обеспечения беспрерывной работы сервис-меша. Переход от политики ротации сертификатов «Never» к «Always» Ранее, в версии cert-manager 1.17 и старше, значение по умолчанию для RotationPolicy было установлено в «Never».
Это означало, что при обновлении сертификата cert-manager лишь продлевал срок его действия, не меняя сам ключ и сертификат. Это решение хоть и допускало обновление срока действия, оставляло фактический секретный ключ прежним, что технически снижало уровень безопасности, ведь со временем ключ становится более уязвимым к компрометации. В версии 1.18 cert-manager изменил эту политику, установив RotationPolicy по умолчанию в значение «Always». Теперь при обновлении сертификата создается новый секретный ключ, что соответствует лучшим практикам безопасности.
Такая ротация сертификата обеспечивает уменьшение окна уязвимости и укрепляет криптографическую защиту. Однако подобная смена поведения, несмотря на очевидные преимущества, породила новые вызовы для инфраструктур, использующих cert-manager совместно с Linkerd и trust-manager. Как новая политика ротации может повлиять на Linkerd Linkerd в архитектуре безопасности использует так называемый корневой сертификат – trust anchor, который служит основой доверия во всей системе. cert-manager занимается выпуском и ротацией этого корневого сертификата, а trust-manager формирует доверительные пучки (trust bundles), содержащие список доверенных корневых сертификатов, который передается всем участникам сети. Правильная настройка trust-manager подразумевает наличие двух trust anchor сертификатов: текущего и предыдущего.
Это важный момент, позволяющий при ротации сначала добавить новый сертификат в trust bundle, сохраняя старый, чтобы все сервисы могли использовать старый сертификат до момента, пока не будут рестартованы и не получат обновленный trust bundle. Такой подход исключает любые разрывы связи и обеспечивает плавное обновление. Риск с одной доверенной записью Те установки, в которых trust-manager настроен с одним trust anchor сертификатом, сталкиваются с проблемой при переходе на новую политику ротации cert-manager. При обновлении cert-manager ключ и сертификат действительно меняются, а trust-manager удаляет старый сертификат из bundle, оставляя лишь новый. Однако сервисы Linkerd способны продолжать работу только с тем trust anchor, который был им известен в момент запуска и используется до перезагрузки.
В результате возникает ситуация, когда сервисы пытаются проверить TLS-соединения через старый trust anchor, которого уже нет в доверительном пучке. Это ведет к ошибкам установления соединения, сбоям в mTLS-связи и потенциальным простоям. Почему с RotationPolicy «Never» таких проблем не было До версии 1.18 cert-manager не менял сам ключ сертификата, а только обновлял срок его действия. Таким образом, хоть trust-manager и обновлял даты сертификата, сам trust anchor оставался неизменным, что позволяло сервисам Linkerd успешно использовать предыдущий сертификат на время своей работы без сбоев.
Нововведение в cert-manager требует адаптации Чтобы избежать ошибок после обновления cert-manager, администраторам важно проверить конфигурацию trust-manager. Первое и простое действие – проверить количество trust anchor сертификатов в разделе sources у ресурса Bundle. Наличие одной записи – сигнал к необходимости настройки второго сертификата, старого, который должен оставаться в bundle до полной миграции сервисов на новый trust anchor. Практически это означает необходимость поддержки двух сертификатов одновременно: старого и нового, с аккуратным управлением времени их действия. Это позволяет seamless, то есть бесшовно, управлять обновлениями, исключая перерывы в связи между микросервисами.
Лучшие практики безопасного обновления cert-manager Прежде чем приступить к обновлению cert-manager до версии 1.18, необходимо сделать аудит текущих конфигураций доверительных пучков. Сравните свои настройки с актуальной документацией Linkerd, так как в ней описаны рекомендации по работе с trust-manager и управления trust anchor сертификатами. Рекомендуется протестировать обновление в тестовой среде, чтобы убедиться, что при смене trust anchor сертификата происходит аккуратное добавление нового элемента в bundle без удаления старого до завершения рестартов сервисов. Такой подход снизит риск прерывания mTLS-связи.
Если у вас возникнут вопросы и сложные моменты, можно обратиться в службу поддержки Buoyant или сообщество Linkerd в Slack, где специалисты помогут решить вопросы и предложат лучшие решения. Перспективы развития управления сертификатами в Linkerd Команда Linkerd активно работает над упрощением процесса управления сертификатами и улучшением инструментов мониторинга доверительных цепочек. В будущем планируется внедрение более интегрированных решений, которые позволят автоматически обнаруживать и предотвращать проблемы на этапе ротации сертификатов, снижая нагрузку на администраторов. Это направление развития поможет сделать сервис-меши еще более надежными и безопасными, что крайне важно в современной динамично меняющейся облачной инфраструктуре. Заключение Обновление cert-manager до версии 1.
