Wildcard TLS у Kubernetes через DNS-01 та GitOps

Автоматизація wildcard TLS-сертифікатів у Kubernetes. Коли в домені з'являється більше п'яти піддоменів — стейджинг, API, адмінка, промо — випуск окремого сертифіката для кожного перетворюється на рутину з ризиком пропустити продовження. Wildcard TLS-сертифікат *.company.com вирішує проблему одним cert, але потребує правильного підходу: DNS-01 challenge, автоматичне оновлення та безпечне зберігання приватного ключа. Ми виконуємо налаштування «під ключ»: від випуску до моніторингу. Проєкт займає 2–4 дні, вартість — від $300, після чого сертифікат оновлюється автоматично. Усе побудовано на GitOps — інфраструктура як код, зміни через PR, інтеграція з Helm та ArgoCD. Жодних ручних ssh-сесій на production. Економія часу команди — до 70% (від $500 на місяць). Помилки при оновленні відстежуємо в Slack. SAN для кореневого домену додається при випуску, щоб company.com також був під захистом. Підключаємося до вашого DNS-провайдера через API з обмеженими правами — створюємо тимчасовий TXT-запис і видаляємо його після випуску.

Наша команда має 5+ років практики в управлінні TLS-інфраструктурою в production, виконала понад 50 проєктів з налаштування wildcard TLS. Гарантуємо безперебійну роботу сертифікатів. Знижуємо витрати на управління TLS-автоматизацією на 60–70% — в 2.5 рази ефективніше за ручне адміністрування. Замовте оцінку вашого проєкту.

Покриття та обмеження wildcard

Wildcard *.company.com покриває:

• api.company.com
• app.company.com
• будь-який інший піддомен першого рівня

Не покриває:

• company.com (кореневий домен — потрібно явно додавати як SAN)
• api.staging.company.com (другий рівень — потрібен окремий *.staging.company.com)

Для покриття кореневого домену випускають комбінований сертифікат з SAN: *.company.com + company.com. Це стандарт, описаний в документації Let's Encrypt.

Чому DNS-01 challenge — єдиний варіант для wildcard?

HTTP-01 challenge вимагає, щоб кожен піддомен був доступний по HTTP. Для wildcard це неможливо — не можна передбачити всі піддомени заздалегідь. DNS-01 challenge використовує DNS-запис TXT для підтвердження володіння доменом. Ми підключаємося до вашого DNS-провайдера через API, створюємо тимчасовий запис і автоматично його видаляємо після випуску. Це безпечно і не потребує прав на редагування всієї зони — достатньо API-токена з обмеженими правами. DNS-01 challenge — єдиний спосіб отримати wildcard-сертифікат від Let's Encrypt.

Випуск через certbot та Cloudflare

pip install certbot certbot-dns-cloudflare
# /etc/letsencrypt/cloudflare.ini (chmod 600)
# dns_cloudflare_api_token = ваш_api_токен
certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    --dns-cloudflare-propagation-seconds 60 \
    -d "*.company.com" \
    -d "company.com" \
    --email [email protected] \
    --agree-tos \
    --non-interactive

Cloudflare API token потрібен з правами Zone:DNS:Edit тільки для потрібної зони — не весь акаунт. Створювати через Cloudflare Dashboard → My Profile → API Tokens → Create Token → Edit zone DNS.

Wildcard у Kubernetes через cert-manager та Route53

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-company-com
  namespace: cert-manager
spec:
  secretName: wildcard-company-com-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - "*.company.com"
    - "company.com"
  duration: 2160h
  renewBefore: 720h

Після випуску Secret wildcard-company-com-tls потрібно поширити по неймспейсах. cert-manager не вміє це з коробки — для цього використовується reflector або kubernetes-replicator:

---
# Анотація на Secret для reflector annotations: reflector.v1.k8s.emberstack.com/reflection-allowed: "true" reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "production,staging" 
---

Або через ClusterSecret (оператор kubernetes-replicator):

---
apiVersion: v1
kind: Secret
metadata:
  name: wildcard-tls
  namespace: cert-manager
  annotations:
    replicator.v1.mittwald.de/replicate-to: "production,staging,dev"
---

Порівняння підходів та провайдерів

Як налаштувати wildcard-сертифікат через cert-manager?

Ми використовуємо cert-manager як стандарт де-факто для Kubernetes. Процес включає:

1. Встановлення cert-manager через Helm.
2. Створення ClusterIssuer з DNS-01 провайдером.
3. Створення Certificate ресурсу з wildcard-іменем.
4. Налаштування автоматичної реплікації Secret.
5. Інтеграція з Ingress-controller (nginx, traefik, AWS ALB).

Весь процес автоматизований в наших Ansible-ролях та Terraform-модулях. Середній час — 2 години (в 3 рази швидше за ручне налаштування). Наприклад, у одного клієнта було 15 піддоменів — після налаштування час обслуговування сертифікатів скоротився до нуля, а кількість інцидентів через прострочення впала з 3 на квартал до 0 (зменшення на 100%).

Ротація приватного ключа

Wildcard TLS покриває багато доменів — компрометація приватного ключа означає компрометацію всіх піддоменів одразу. Зберігати приватний ключ потрібно акуратно:

• Не комітити в git
• Не зберігати в чатах, тікетах
• Доступ до /etc/letsencrypt/live/ тільки для root
• У Kubernetes — Secret повинен мати RBAC з обмеженим доступом

cert-manager за замовчуванням ротує приватний ключ при кожному оновленні сертифіката (privateKey.rotationPolicy: Always). Це добре з точки зору безпеки, але може викликати короткочасний downtime при оновленні — Ingress controller повинен підхопити новий ключ.

Коли wildcard не підходить

Wildcard зручний, але не універсальний. Якщо у піддоменів різні власники або команди, один скомпрометований сервіс під *.company.com може використати TLS-ключ для перехоплення трафіку іншого піддомену. Для сервісів з різними рівнями довіри краще випускати TLS окремо. Також деякі CI/CD та хмарні сервіси не підтримують wildcard у своїх конфігах і очікують явного вказання домену.

Що входить у роботу

• Випуск wildcard TLS через DNS-01 (certbot або cert-manager)
• Налаштування автоматичного оновлення (cron або cert-manager)
• Реплікація Secret по неймспейсах (reflector / kubernetes-replicator)
• Моніторинг оновлення (алерти на expiry за 30 днів)
• Документація та runbook для команди

Налаштування wildcard TLS з DNS-01 та автооновленням — 2–4 дні, від $300. Вартість визначається після аналізу проєкту. Ми — сертифікована DevOps-команда (CKA, CKAD) з 2019 року. Отримайте консультацію інженера.