cert-manager Kubernetes: англійський словник для автоматизації TLS

Керування сертифікатами є однією з тих тем, що спричиняють реальні інциденти, коли щось йде не так, а коли це відбувається, команди повинні спілкуватися чітко і швидко. Для людей, для яких англійська не є рідною мовою, що працюють з Kubernetes, словник навколо cert-manager, TLS і протоколу ACME є як технічним, так і на диво ідіоматичним. Знаючи правильні слова, ви не тільки зможете слідкувати за викликами, але й повідомите команді, що ви добре розумієте систему. У цьому повідомленні ви дізнаєтесь про англійську лексику і шаблони спілкування для обговорень з керування сертифікатами, починаючи з перегляду повсякденних операцій і закінчуючи випадками закінчення терміну дії сертифікатів під час надзвичайних ситуацій.

Ключовий словник

** Ресурс сертифіката ** — У cert-manager, Certificate є нетиповим ресурсом Kubernetes, який описує потрібний сертифікат X.509. Інженери кажуть « ми створюємо ресурс сертифіката » або « об’ єкт сертифіката вказує домен ». Зауважте велику літеру « С », коли мова йде про ресурс Kubernetes.

«Ресурс Сертифікат у цьому просторі імен не відновлювався протягом трьох днів — стан показує, що він застряг у стані Issuing і виклик ACME не завершується»

** Видавач проти ClusterIssuer** — Issuer є ресурсом cert-manager, обсяг якого обмежений одним простором імен; ClusterIssuer є кластерним. Інженери кажуть «ми використовуємо ClusterIssuer для Let’s Encrypt» або запитують «чи повинен це бути Issuer або ClusterIssuer?»

«Ми перенесли все в ClusterIssuer, щоб всі простори імен могли використовувати ту ж саму конфігурацію Let’s Encrypt — маючи на кожному просторі імен Issuers створювали додаткові витрати на обслуговування»

** Протокол ACME ** — протокол середовища автоматичного керування сертифікатами, який використовується програмою Let’ s Encrypt для перевірки власника домену і видачі сертифікатів. Произносится “АК-ми”. Инженеры говорят “ACME flow”, “ACME challenges”, или “cert-manager handles ACME handshake.”

«ACME — це протокол, який Let’s Encrypt використовує для того, щоб довести, що ви насправді контролюєте домен перед видачею сертифіката — cert-manager автоматизує весь процес для вас»

** Поновлення сертифіката ** — процес отримання нового сертифіката перед закінченням терміну дії поточного. cert- manager обробляє цю інформацію автоматично. Інженери кажуть «cert-manager обробляє оновлення» або «сертифікат готовий до оновлення» або «оновлення зазнало невдачі»

“cert- manager типово починає процес поновлення за 30 днів до закінчення терміну дії сертифіката. Якщо оновлення продовжує зазнавати невдач, сертифікат зрештою закінчується і HTTPS розривається — саме тому ми попереджуємо про оновлення, які застрягли»

** Сертифікат X. 509 ** — стандартний формат для сертифікатів TLS. Інженери кажуть «X.509 cert», «X.509 сертифікат», або просто «сертифікат» в контексті. Під час обговорення полів сертифікатів ви почуєте « специфікація X. 509 ».

Сертифікат X.509 містить назву домену, відкритий ключ, орган, що видав сертифікат, і дату закінчення терміну дії — всю інформацію, яку браузер повинен перевірити HTTPS

** Запит на підписання сертифіката (CSR) ** — блок зашифрованих даних, надісланих до центру сертифікації (CA) з запитом на сертифікат. Інженери кажуть « менеджер сертифікатів створює запит на сертифікат » або « центр сертифікації підписує запит на сертифікат ». Вимовляється за допомогою написання літер: « C- S- R. »

“Під капотом, cert-manager генерує CSR з вашим приватним ключем і відсилає його на сервер ACME. Якщо виклик успішний, CA підписує CSR і повертає сертифікат. ”

** Сертифікат з підмножини символів ** — Сертифікат, який охоплює всі піддомени домену (наприклад, *.example.com ). Інженери кажуть «ми використовуємо сертифікат з підказкою» або «сертифікати з підказкою вимагають виклику DNS-01»

«Ми видає сертифікат wildcard для *.internal.company.com, тому нам не потрібно забезпечувати окремі сертифікати для кожної внутрішньої служби. DNS-01 є єдиним типом виклику ACME, який підтримує шаблони»

** DNS-01 виклик проти HTTP-01 challenge** — Два методу, які ACME використовує для перевірки власності на домен. HTTP-01 розміщує токен на певному URL; DNS-01 додає TXT-запис до DNS. Інженери кажуть: «ми використовуємо HTTP-01 для публічного вступу» або «для шаблонів, ви повинні використовувати DNS-01»

«DNS-01 є більш гнучким, але вимагає, щоб cert-manager мав доступ до API до вашого DNS-провайдера для створення TXT-записів. HTTP-01 простіше — йому просто потрібен HTTP-сервер, доступний на порту 80

** Ланцюг сертифікатів ** — повна послідовність сертифікатів від вашого сертифіката кінцевої точки до надійного кореневого центру сертифікації, включаючи всі проміжні сертифікати. Інженери кажуть «обслуговувати повний ланцюг» або «ланцюг сертифікатів є неповним»

«TLS handshake зазнає невдачі, тому що сервер обслуговує тільки листовий сертифікат, а не повний ланцюг — браузери не можуть перевірити шлях довіри без посередників»

** PKCS# 8 ** — стандартний формат для зберігання закритих ключів. cert- manager може виводити закритий ключ у форматі PKCS# 8. Вимовляється як « P- K- C- S вісім ». Інженери кажуть « закритий ключ у форматі PKCS# 8 » або « деякі інструменти вимагають PKCS# 8 замість PKCS# 1 »

«Старіша програма Java очікує закритий ключ у форматі PKCS#8, але cert-manager виводить PKCS#1 за замовчуванням — нам потрібно додати privateKey: encoding: PKCS8 до специфікації сертифіката»

** Ротація сертифікатів ** — це більш широка практика регулярної заміни сертифікатів, навіть до закінчення їх терміну дії, для зменшення ризику. Інженери кажуть “ми змінюємо сертифікати”, “примусове зміна сертифікатів”, або “політика зміни”

«Після інциденту з CA, ми викликали примусову ротаційну сертифікацію по всіх сервісах, щоб замінити будь-які потенційно скомпрометовані сертифікати — cert-manager зробив це простим, просто вилучив і відновив ресурс Сертифікат»

Фрази в контексті

** Діагностика помилки відновлення при виклику інциденту: **

“Стартовий сертифікат для api.example.com закінчився близько 20 хвилин тому. Я дивлюся на журнали cert- manager і здається, що виклик HTTP- 01 не спрацював останній тиждень — сервер ACME не може досягти нашого входу на порт 80. Я думаю, що недавня зміна мережевої політики заблокувала цей шлях»

** Пояснення налаштування сертифіката у перегляді архітектури: **

«Ми використовуємо ClusterIssuer, підтримуваний Let’s Encrypt для всіх публічно доступних послуг. cert-manager автоматично обробляє повний потік ACME — він генерує CSR, завершує виклик, отримує сертифікат і зберігає його як секрет Kubernetes. Поновлення відбувається через 30 днів, тому на практиці ми ніколи не торкаємося сертифікатів вручну»

** Питання про тип завдання в обговоренні планування: **

«Для нового шаблону *.staging.example.com нам буде потрібен DNS-01 — HTTP-01 не підтримує шаблони. Чи наша установка cert-manager вже має API доступ до Route 53, чи нам потрібно налаштувати webhook для цього?»

Описуючи рішення про певну поворотність в пост-мортному:

«Після того, як ми визначили обсяг компромісу CA, ми вирішили зробити повну ротацію сертифікатів у всіх трьох кластерах. Оскільки ми використовуємо cert-manager з ресурсами Сертифікат, ми могли запустити його, просто вилучивши і відтворюючи об’єкти Сертифікат — контролер займався рештою»

Ключові слова

• ** видання сертифіката ** / ** видання сертифіката центром сертифікації ** (не « видача сертифіката »)
• ** термін дії сертифіката закінчується ** / ** термін дії сертифіката закінчується ** (а не « термін дії сертифіката закінчується »)
• ** відновити сертифікат ** / ** викликати відновлення ** (не « оновити сертифікат »)
• ** завершити виклик ** / ** невдача виклику ** (контекст ACME)
• ** trust chain ** / ** chain of trust ** — пов’ язана послідовність сертифікатів
• ** закритий ключ ** (майже завжди два слова, не « закритийключ » у мові)
• cert rotation — часто неформальна абревіатура, що використовується в DevOps: « нам потрібна ротаційна сертифікація »
• ** annotate the ingress ** — налаштування cert- manager для ресурсу вхідних даних: « annotate the ingress with the ClusterIssuer name »

Practice

Загляньте до документації з cert- manager щодо специфікації ресурсу Certificate і знайдіть три параметри налаштування, якими ви раніше не скористалися. Потім напишіть короткий запис у Runbook для розв’ язання проблем — від чотирьох до шести пунктів — з описом того, як діагностувати невдалу спробу відновлення сертифіката у Kubernetes. Використовуйте принаймні шість слів з цього повідомлення. Писання записів runbook є однією з найпрактичніших навичок англійської мови для інженерів DevOps: вам потрібно бути ясним, коротким і точним, оскільки хтось інший буде виконувати ваші інструкції під тиском. Сфокусуйтеся на виборі дієслова — « перевірити », « перевірити », « вилучити і відтворити », « анотувати » — оскільки це слова дій, які рідні носії мови використовують у операційній документації.