cert-manager в Kubernetes: почему TLS-сертификаты истекают
Продление TLS-сертификатов в кластере почти всегда настроено — и почти всегда ломается незаметно. Сертификат на входящий трафик живёт ограниченный срок, продление идёт фоновым процессом, и именно поэтому за ним никто не следит: пока цепочка валидна, метрики выглядят здоровыми, ошибок в логах нет.
Дальше крайний срок проходит молча. Приложения работают, деплой в порядке, но браузеры и мобильные клиенты отказываются от соединения — и это уже не сбой одного сервиса, а отказ входящего трафика по всему домену. Клиенты с жёсткой проверкой цепочки доверия падают с ошибкой TLS, а ручной выпуск сертификатов в этот момент растягивается на часы: нужно успеть выпустить новый, положить его в секрет и перезапустить поды.
Причин у такого сценария обычно три. Продление настроено, но ошибки проверки владения доменом никто не разбирает: запись для DNS-01 осталась прежней, путь для HTTP-01 закрыт правилом маршрутизации или защитой от внешних запросов — и контроллер молча повторяет попытку до самого дедлайна. Ручной выпуск сертификатов оставляет секреты с прежними именами и ссылки на старый объект, поэтому обновлённая цепочка просто не попадает в под. А уведомление о том, что срок истекает, не привязано ни к одному каналу оповещения.
Цена у этих мелочей одна — недоступность сервиса в самый неудачный момент. Разбираем, как это закрывается и что должно быть настроено до того, как крайний срок пройдёт.
Что даёт автоматическое управление сертификатами в кластере
В кластере сертификаты перестают быть ручной задачей: каждый описывается декларативно — объект Certificate ссылается на ClusterIssuer, а результат ложится в Secret, который читает ингресс. Единая точка управления означает, что выпуск, хранение и ротация задаются одним манифестом, а не обходом панелей разных сервисов. Сокращение ручных операций измеряется числом шагов: новый домен — это коммит, а не заявка в очередь.
Автоматическое продление сертификатов завязано на оставшийся срок жизни: контроллер видит, что до истечения осталось меньше заданной доли, и перевыпускает сертификат заранее, обновляя Secret. Ингресс-контроллер подхватывает новое содержимое без перезапуска подов, поэтому снижение времени простоя — не «почти ноль», а ровно ноль: окно продления настолько широкое, что обрыв соединения не наступает.
Главный эффект — устранённый класс отказов. Истёкший сертификат, забытый на тестовом стенде, wildcard, продлённый только в одном окружении, рассинхрон между кластерами — всё это перестаёт быть инцидентом и становится задачей контроллера. Предсказуемое поведение при массовом обновлении тоже обеспечено: запросы к центру сертификации идут с ограничением скорости и повторами, поэтому волна перевыпусков не превращается в отказ.
Остаётся контроль: метрики по сроку действия, события при неудачной проверке домена, алерт до наступления критической даты. Такой набор и есть чек-лист зрелости — продление без человека, единая точка управления, ноль ручных операций и отсутствие целого класса инцидентов.
Режимы работы cert-manager в Kubernetes: сравнение подходов
<cite>cert-manager</cite> не выпускает сертификаты сам — он описывает источник подписи через объекты Issuer или ClusterIssuer, а Certificate задаёт домены и срок жизни. От выбора источника зависят автоматическая ротация, доверие на стороне клиентов и то, как проходит отзыв при компрометации ключа.
Режимы спокойно комбинируются в одном кластере: публичные сертификаты — для внешних сервисов, внутренний центр — для трафика между сервисами, самоподписанные — только на временных контурах. Ниже четыре варианта и ограничения каждого.
| Вариант выпуска | Когда подходит | Ограничения |
|---|---|---|
| Публичный удостоверяющий центр | Внешние домены и клиенты, у которых нет корпоративного корневого сертификата | Нужна проверка владения доменом, есть пределы на число выпусков, сертификат попадает в публичные журналы |
| Внутренний удостоверяющий центр организации | Сервисы внутри сети, взаимная аутентификация между сервисами | Клиентам нужно доверять корневому сертификату; нужен регламент выпуска и отзыва |
| Корпоративное хранилище секретов | Уже есть централизованное хранилище ключей и требования по аудиту доступа | Требуется синхронизация состояния кластера и хранилища, права выдаются отдельно |
| Самоподписанные сертификаты | Тестовые и временные контуры, отладка | Браузеры и внешние клиенты не доверяют; в продуктив такой сертификат не переносится |
На практике в одном кластере обычно живут два-три режима: внешний контур на публичном центре, внутренний — на своём, и отдельный самоподписанный для проверок. Выбор фиксируем в схеме эмитентов и политике ротации, чтобы новый сервис не тянул сертификат вручную, а отзыв занимал минуты, а не часы.
Этапы внедрения автоматического продления сертификатов
Автоматическое продление ломается не на выдаче сертификата, а на краях: домен, который забыли добавить в описание, или приватный ключ в единственном экземпляре. Поэтому этапы внедрения выстроены от инвентаризации до приёмки — результат каждого шага проверяем до того, как он попадёт в рабочий контур.
- Аудит конфигурации кластера. Собираем все точки, где завершается защищённое соединение, фиксируем домены, сроки действия и места хранения ключей. На выходе — реестр с ответственным по каждой записи.
- Схема доверия. Определяем удостоверяющий центр, порядок выдачи промежуточных сертификатов и способ подтверждения владения доменом. Отдельно решаем, где лежат ключи и как они ротируются.
- Настройка выпуска. Описываем сертификаты декларативно, привязываем к доменам и задаём окно продления с запасом — за 30 дней до истечения остаётся время разобрать сбой без спешки.
- Проверка продления на копии контура. Принудительно запускаем цикл на тестовом окружении: смотрим цепочку, порядок подмены сертификата и поведение сервисов, когда центр выдачи недоступен.
- Приёмка. Настраиваем наблюдение за сроком действия и оповещения заранее, прогоняем полный цикл на рабочем контуре в согласованное окно.
- Передача в эксплуатацию. Отдаём регламент продления, схему размещения ключей и список ответственных за реакцию на оповещение.
Дальше продление идёт без ручных действий, а отказ виден раньше, чем сертификат истёк.
Что остаётся у команды после внедрения автоматизации
Автоматизация без документации создаёт зависимость от того, кто её настраивал: уходит инженер — и выпуск сертификатов превращается в необъяснимый чёрный ящик. Поэтому в передачу входит не только работающий контур, но и набор артефактов, по которым дежурная смена и новые специалисты действуют без нас.
- Схема взаимодействия — как заявка на домен превращается в готовый сертификат: способ подтверждения владения, место хранения ключей, связь выпуска с объектами маршрутизации. Диаграмма плюс текстовое описание каждого шага.
- Документация по сертификатам — опись всех выпускаемых объектов: домены, типы (одиночный, wildcard, с несколькими именами), срок действия, ответственный за домен, где сертификат используется.
- Регламент продления — за сколько дней до истечения запускается продление, что происходит при неудачной попытке, кому уходит уведомление и в каком порядке сертификат выпускается вручную.
- Политики доступа — роли и права: кто меняет настройки выпуска, кто читает секреты, у кого доступ к управлению DNS-записями для подтверждения владения.
- Инструкции для дежурной смены — разбор типовых отказов: истёкший сертификат, ошибка подтверждения домена, исчерпанная квота у внешнего поставщика — с указанием, что проверять первым.
- Мониторинг и оповещения — дашборд по срокам жизни сертификатов и алерты на порог, при котором ещё остаётся время на ручное вмешательство.
- Процедура отката — как вернуть предыдущую конфигурацию выпуска и как временно отключить автоматизацию, не уронив маршрутизацию.
Комплект собирается под ваш контур: имена объектов, адреса панелей и зоны ответственности подставляются ваши, а не остаются примерами из документации.
Кейс: как мы убрали ручное продление сертификатов
Контекст: среда распределённая — четыре контура (разработка, тест, предпродуктив, продуктив) и три региона, около 60 доменов и поддоменов, включая подстановочные сертификаты для внутренних сервисов. Сертификаты оформлялись вручную: инженер вёл таблицу сроков, подавал заявки в удостоверяющий центр и раскладывал файлы по балансировщикам и контроллерам. За квартал набегало под 40 операций, а истечение одного сертификата означало отказ внешнего интерфейса и ошибки у клиентов.
cert-manager поставили оператором в кластер и описали выпуск декларативно: отдельный источник на каждое окружение, общий — для доменов верхнего уровня. Продление стартует за 30 дней до истечения, ключ обновляется в том же пространстве имён и подхватывается без перезапуска приложения. Отдельно вывели метрику остатка срока: предупреждение за 21 день, критичный алерт — за 7.
Что изменилось в цифрах
- Плановые ручные операции: около 40 в квартал → 0.
- Инциденты из-за истёкших сертификатов: 9 за год → 0.
- Выпуск нового домена: 2-3 дня с согласованиями → 15-25 минут от правки манифеста до готового сертификата.
- Ошибки продления (недоступна проверка владения доменом, разъехались зоны) раньше всплывали в момент истечения — теперь видны алертом за три недели; доля успешных автопродлений за год — 100%.
Ручными остались только смена DNS-провайдера и разовые исключения — они описаны в инструкции для дежурного, разбор занимает минуты, а не часы.
Что делать, если сертификаты уже выдаются вручную?
Миграция на автоматизацию — это не переключатель, а последовательность. На первом этапе две схемы сосуществуют: cert-manager в кластере не трогает уже созданные Secret, потому что связь между описанием Certificate и хранилищем возникает только по имени и пространству имён, которые задаёте вы сами. Пока описания нет, ручные сертификаты продолжают работать и продлеваются в прежнем порядке.
Первый шаг — проверка на небоевом пространстве имён. Выпускаем сертификат на тестовый домен тем же способом, которым потом будут выпускаться боевые: проходит ли подтверждение владения доменом, попадает ли полная цепочка в Secret, подхватывает ли её входной контроллер без перезапуска приложений. Так проверяется не только выпуск, но и то, что цепочка доверия полная — иначе клиенты увидят предупреждение, которое не поймать внутри кластера.
Когда результат сходится с ожидаемым, описания переносятся на реальные домены по одному: сначала менее нагруженный контур, затем остальные. Ручные сертификаты не удаляются — они остаются рабочим откатом, пока автоматически выпущенный не проживёт полный цикл продления.
Продление — главное, ради чего всё затевается. Автоматика обновляет Secret заранее, до истечения срока, а приложение читает новый файл без ручного вмешательства. Если продление сорвалось из-за недоступности центра сертификации или изменённых прав, возврат к ручной выдаче занимает одно действие.
Отдельно закрываются доступы: право обновлять Secret и объекты описаний, доступ к зоне домена для подтверждения владения, запас по числу запросов к центру сертификации. Без этого автоматизация работает до первой смены DNS или расширения прав — и снова превращается в ручную.
Технические сомнения, которые стоит снять до старта
До старта обычно всплывают четыре вопроса: где выпускать сертификаты, что делать с сервисами за пределами кластера, как пройдёт проверка владения доменом и сработает ли продление без ручного вмешательства. Ниже — короткие ответы, которые снимают большую часть сомнений ещё до работ.
Внешний удостоверяющий центр или внутренний?
Внешний публичный центр берём для всего, что видят пользователи и внешние клиенты — браузеры доверяют ему без дополнительной настройки. Для внутренних сервисов разворачиваем собственный удостоверяющий центр: корневой сертификат попадает в доверенные хранилища узлов и клиентских машин, а выпуск идёт внутри контура без внешних зависимостей. Смешанная схема — норма: разные выпускающие объекты для внешнего и внутреннего трафика, чтобы отказ внешнего центра не затрагивал служебные связи.
Что делать с сервисами вне кластера?
Сертификаты выпускаются и для них: секрет с ключом и цепочкой читает внешний балансировщик или обратный прокси, либо он забирает обновление из общего хранилища. Критично другое — чтобы после продления секрет перечитался процессом, а не остался в памяти до ручного перезапуска. Проверяем это на стенде: сокращаем срок жизни, ждём автоматического обновления и смотрим, подхватил ли новый сертификат внешний потребитель.
Как пройдёт проверка владения доменом?
Через веб-сервер — если домен указывает на кластер и есть куда положить проверочный файл. Через DNS — если нужны сертификаты на группу поддоменов сразу или публичного входа нет вовсе; тогда выпускающему объекту нужны права на изменение записей у DNS-провайдера, и мы выдаём их узко, только на нужную зону. Для внутренних доменов проверка владения не требуется.
Как убедиться, что продление сработает заранее?
Продление стартует заметно раньше истечения, поэтому сбой успевает попасть в мониторинг, а не в отчёт об аварии. Ставим оповещения на возраст сертификата, на ошибки выпуска и на исчерпание попыток проверки владения, плюс контрольный прогон на тестовом контуре с укороченным сроком жизни. Дальше вопрос только в доступе к DNS и в резервном канале проверки — если основной провайдер недоступен.
Обсудим вашу задачу и вернёмся с планом
Чтобы оценка работ опиралась на факты, а не на допущения, нам нужен срез вашей инфраструктуры: как сертификаты выпускаются сейчас, где живут ключи и что именно должно попасть под автоматизацию. Ниже — минимальный набор данных, из которого собирается предметный план внедрения. Если чего-то нет под рукой, разберёмся на созвоне и уточним в переписке.
- Состав контуров. Сколько кластеров Kubernetes, где они размещены (облако, свои серверы, гибрид), сколько пространств имён и точек входа трафика приходится обслуживать. От этого зависит, нужен ли один общий выпускающий центр или отдельные на каждый контур.
- Текущая схема выпуска. Кто выдаёт сертификаты сегодня — вручную, скриптами или внешним сервисом; где хранятся приватные ключи; какие типы нужны: одиночные домены, wildcard, внутренние имена.
- Список сервисов на периметре. Домены и поддомены под автоматизацию с пометкой, какие публичные, а какие доступны только из внутренней сети. Это определяет способ подтверждения прав на домен и объём проверок после переключения.
- Доступы и точки интеграции. Как вносятся DNS-записи, кто управляет зонами, есть ли внешнее хранилище секретов и как к нему подключаются рабочие нагрузки.
- Ограничения по срокам. Жёсткие даты, окна обслуживания, допустимость короткого перерыва в TLS при переключении и требования аудита к сроку жизни ключей.
- Прошлый опыт. Что уже пробовали, какие были инциденты с истечением сертификатов и что именно не устроило в предыдущем решении.
С этим набором мы фиксируем состав работ, порядок этапов, точки отката и критерии приёмки. Опишите задачу в удобном формате — вернёмся с оценкой и планом.
