Автоматизация TLS-сертификатов в Kubernetes с Cert-Manager

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

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

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

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

Какие проблемы решаем

• Просроченные сертификаты: при ручном управлении легко пропустить дату истечения. Cert-Manager автоматически обновляет сертификат за 30 дней до конца срока. В нашей практике это исключило 100% простоев по expired-сертификатам.
• Ошибки конфигурации: неверные пути к ключам, несовместимые алгоритмы. Cert-Manager использует стандартные ресурсы Kubernetes и проверяет корректность. ECDSA-256 даёт более быстрый TLS-хэндшейк по сравнению с 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-хэндшейк по сравнению с RSA-2048 — снижение времени handshake до 30%.

Кейс из практики: недавно мы внедрили Cert-Manager для клиента из финтеха. У них было 15 микросервисов, каждый с отдельным TLS. До автоматизации команда тратила 2 часа в неделю на ручное продление. После настройки — zero-touch, и количество TLS-инцидентов ушло в ноль. Затраты на поддержку снизились на 35%, что эквивалентно экономии 15 000 USD в год.

"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 рабочих дней. Стоимость — от $270–390 (базовая конфигурация HTTP-01) до $630–910 (DNS-01 с несколькими провайдерами). В работу входит:

• Установка и настройка 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% случаев.

Типичные ошибки и как избежать