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 задає домени та термін дії.
Від вибору джерела залежать автоматична ротація, довіра на боці клієнтів і те, як проходить відкликання при компрометації ключа.
Режими спокійно комбінуються в одному кластері: публічні сертифікати — для зовнішніх сервісів, внутрішній центр — для трафіку між сервісами, самопідписані — лише на тимчасових контурах. Нижче чотири варіанти та обмеження кожного.
| Варіант випуску | Коли підходить | Обмеження |
|---|---|---|
| Публічний центр сертифікації | Зовнішні домени та клієнти, у яких немає корпоративного кореневого сертифіката | Потрібна перевірка володіння доменом, є межі на кількість випусків, сертифікат потрапляє в публічні журнали |
| Внутрішній центр сертифікації організації | Сервіси всередині мережі, взаємна автентифікація між сервісами | Клієнтам потрібно довіряти кореневому сертифікату; потрібен регламент випуску та відкликання |
| Корпоративне сховище секретів | Уже є централізоване сховище ключів і вимоги щодо аудиту доступу | Потрібна синхронізація стану кластера та сховища, права видаються окремо |
| Самопідписані сертифікати | Тестові та тимчасові контури, налагодження | Браузери та зовнішні клієнти не довіряють; у продуктив такий сертифікат не переноситься |
На практиці в одному кластері зазвичай живуть два-три режими: зовнішній контур на публічному центрі, внутрішній — на своєму, і окремий самопідписаний для перевірок.
Вибір фіксуємо в схемі емітентів і політиці ротації, щоб новий сервіс не тягнув сертифікат вручну, а відкликання займало хвилини, а не години.
Етапи впровадження автоматичного продовження сертифікатів
Автоматичне продовження ламається не на видачі сертифіката, а на краях: домен, який забули додати в опис, або приватний ключ в єдиному екземплярі.
Тому етапи впровадження вибудувані від інвентаризації до приймання — результат кожного кроку перевіряємо до того, як він потрапить у робочий контур. Вартість розраховується після аудиту. 1. Аудит конфігурації кластера.
Збираємо всі точки, де завершується захищене з'єднання, фіксуємо домени, терміни дії та місця зберігання ключів. На виході — реєстр з відповідальним за кожним записом. 2. Схема довіри.
Визначаємо центр сертифікації, порядок видачі проміжних сертифікатів і спосіб підтвердження володіння доменом. Окремо вирішуємо, де лежать ключі та як вони ротуються. 3. Налаштування випуску.
Описуємо сертифікати декларативно, прив'язуємо до доменів і задаємо вікно продовження із запасом — за 30 днів до закінчення залишається час розібрати збій без поспіху. 4. Перевірка продовження на копії контуру.
Примусово запускаємо цикл на тестовому середовищі: дивимося ланцюжок, порядок підміни сертифіката та поведінку сервісів, коли центр видачі недоступний. 5. Приймання.
Налаштовуємо спостереження за терміном дії та оповіщення заздалегідь, проганяємо повний цикл на робочому контурі в узгоджене вікно. 6. Передавання в експлуатацію. Віддаємо регламент продовження, схему розміщення ключів і список відповідальних за реакцію на оповіщення.
Далі продовження йде без ручних дій, а відмова видна раніше, ніж сертифікат закінчився.
Що залишається в команди після впровадження автоматизації
Автоматизація без документації створює залежність від того, хто її налаштовував: іде інженер — і випуск сертифікатів перетворюється на незрозумілу чорну скриньку.
Тому в передавання входить не лише робочий контур, а й набір артефактів, за якими чергова зміна та нові фахівці діють без нас.
- Схема взаємодії — як заявка на домен перетворюється на готовий сертифікат: спосіб підтвердження володіння, місце зберігання ключів, зв'язок випуску з об'єктами маршрутизації. Діаграма плюс текстовий опис кожного кроку.
- Документація щодо сертифікатів — опис усіх об'єктів, що випускаються: домени, типи (одиночний, 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 під час перемикання та вимоги аудиту до терміну життя ключів.
- Минулий досвід. Що вже пробували, які були інциденти із закінченням сертифікатів і що саме не влаштувало в попередньому рішенні.
З цим набором ми фіксуємо склад робіт, порядок етапів, точки відкату та критерії приймання. Опишіть задачу у зручному форматі — повернемося з оцінкою та планом.
