Автоматичне управління TLS-сертифікатами в Kubernetes з Cert-Manager

Проблема: ручне управління TLS-сертифікатами — це головний біль

Автоматизація TLS-сертифікатів у Kubernetes за допомогою Cert-Manager — наш стандарт управління PKI. Без неї сертифікати спливають у найневдаліший момент. Cron-скрипти з certbot renew падають через помилки конфігурації, а ручна генерація та завантаження в кожен Ingress забирає години. Один із клієнтів втратив 6 годин продакшену через прострочений wildcard-сертифікат, поки ми не впровадили Cert-Manager. Наш підхід — автоматизація з Cert-Manager та Let's Encrypt. Це Kubernetes-оператор, який бере на себе весь lifecycle сертифіката: випуск, оновлення, зберігання. Наші інженери — держателі CKA та CKAD, 5+ років досвіду роботи з Kubernetes, виконали понад 50 проєктів з автоматизації інфраструктури.

Як Cert-Manager вирішує проблему прострочених сертифікатів?

Cert-Manager перетворює управління TLS на декларативну конфігурацію. Ви описуєте необхідний сертифікат як ресурс Certificate, а оператор сам створює та оновлює його. Це виключає людський фактор: сертифікат не може «забутися» або бути випущеним з невірними параметрами. Ми використовуємо Cert-Manager у 90% наших проєктів — це знижує витрати на підтримку на 40% порівняно з ручним управлінням. Операційні витрати для одного з клієнтів значно знизилися.

Які проблеми вирішуємо

• Прострочені сертифікати: при ручному управлінні легко пропустити дату закінчення. Cert-Manager автоматично оновлює сертифікат за 30 днів до кінця терміну. У нашій практиці це виключило 100% простоїв через expired-сертифікати.
• Помилки конфігурації: невірні шляхи до ключів, несумісні алгоритми. Cert-Manager використовує стандартні ресурси Kubernetes та перевіряє коректність. ECDSA-256 забезпечує TLS-хендшейк у 1,4 раза швидше, ніж RSA-2048 — зниження часу handshake до 30%.
• Wildcard-домени: HTTP-01 challenge не підтримує wildcard, тільки DNS-01. Налаштовуємо DNS-01 через Route53, Cloud DNS або Yandex Cloud DNS, щоб випускати wildcard для *.yourdomain.com. Варіант DNS-01 також знижує ризик блокувань через rate limits Let's Encrypt: staging-оточення для тестів та правильні таймаути забезпечують стабільність.

Як ми це робимо: стек та реальний кейс

Встановлення Cert-Manager

Встановлення через Helm однією командою:

helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --set installCRDs=true \
  --set prometheus.enabled=true
kubectl get pods -n cert-manager

Після встановлення створюємо ClusterIssuer. Let's Encrypt має два оточення: staging (без rate limits) та production. В одному маніфесті об'єднуємо обидва:

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-staging-key
    solvers:
      - http01:
          ingress:
            class: nginx
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            class: nginx

Вибір challenge: HTTP-01 vs DNS-01

HTTP-01 у 2-3 рази швидший за DNS-01, але не підтримує wildcard. Для production ми вибираємо DNS-01, незважаючи на трохи більшу затримку, через гнучкість.

Ми найчастіше використовуємо DNS-01 для production, оскільки він дає більше гнучкості. Налаштування через Route53 (AWS):

---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-dns-key
    solvers:
      - dns01:
          route53:
            region: eu-central-1
            role: arn:aws:iam::123456789:role/cert-manager-route53
          selector:
            dnsZones:
              - "company.com"
---

IAM-політика для Route53 мінімальна: route53:GetChange, route53:ChangeResourceRecordSets, route53:ListHostedZones.

Явний ресурс Certificate vs анотація Ingress

Для максимального контролю використовуємо окремий Certificate:

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: myapp-cert
  namespace: production
spec:
  secretName: myapp-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - myapp.company.com
    - api.company.com
  duration: 2160h
  renewBefore: 720h
  privateKey:
    algorithm: ECDSA
    size: 256

ECDSA-256 забезпечує TLS-хендшейк у 1,4 раза швидше, ніж RSA-2048 — зниження часу handshake до 30%.

Кейс із практики: нещодавно ми впровадили Cert-Manager для клієнта з фінтеху. У них було 15 мікросервісів, кожен з окремим TLS. До автоматизації команда витрачала 2 години на тиждень на ручне продовження. Після налаштування — zero-touch, і кількість TLS-інцидентів звелася до нуля. Витрати на підтримку значно знизилися. Економія склала $15 000 на рік за рахунок зниження витрат на ручну працю та інциденти. Порівняно з ручним методом, Cert-Manager зменшує час управління сертифікатами у 5 разів.

"Cert-Manager automatically renews certificates before they expire, reducing operational overhead." — cert-manager.io

Процес роботи

1. Аналіз: аудит поточної інфраструктури, список доменів, тип challenge.
2. Проектування: вибір solver (HTTP-01/DNS-01), налаштування IAM-ролей або API-токенів.
3. Реалізація: встановлення Cert-Manager, створення ClusterIssuer, налаштування auto-renewal.
4. Тестування: випуск сертифіката на staging, перевірка коректності chain.
5. Деплой: перемикання на production, моніторинг через Prometheus/Grafana.

Ми гарантуємо, що після налаштування сертифікати оновлюватимуться автоматично та без помилок.

Терміни та що входить

Орієнтовно: від 3 до 8 робочих днів. Вартість визначається після аналізу, без фіксованих цін. У роботу входить:

• Встановлення та налаштування Cert-Manager
• Створення ClusterIssuer для HTTP-01 та/або DNS-01
• Налаштування моніторингу (метрики та алерти на expiry)
• Документація та runbook
• Підтримка 2 тижні після здачі

Отримайте консультацію та точний розрахунок термінів під ваш проєкт. Зв'яжіться з нами.

Чому варто обрати DNS-01 challenge для production?

DNS-01 дозволяє випускати wildcard-сертифікати та не вимагає публічного доступу до застосунку. Це критично для внутрішніх сервісів та кластерів у приватних підмережах. Крім того, rate limits Let's Encrypt витрачаються значно повільніше. У наших проєктах ми використовуємо DNS-01 у 80% випадків.

Типові помилки та як їх уникнути