Comments 10
Статья интересная, спасибо.
и давать полный доступ к корневой зоне вашего домена какому-то скрипту не всегда есть возможность
Если вдруг у вас уже есть свой DNS-сервер(ы) в инфраструктуре, то давать полный доступ скриптам не надо, вот по этому прекрасному рецепту
https://www.umgum.com/letsencrypt-wildcard-bind9
я делал субзону _acme-challenge.domain.com и давал на нее скрипту права только по TSIG и только на TXT. Работает! Пользуясь случаем, спасибо автору. Подходит для любого современного ДНС поддерживающего TSIG. Если у кого-то более сложная ситуация - primary DNS свой (например, hidden master) а secondary DNS у регистратора или хостера, то такую зону передать на них без api действительно не получится, но в случае с bind9 это решается просто - у него есть директива include. делаете делаете минимальный файл основной зоны, инклюдите еще один и все ручные изменения делаете во втором, а первый пусть обновляется скриптом с помощью rndc. rndc делает первый файл некрасивым, но никогда его не ломает. А на secondary рассылаете notify.
но можно выпускать сертификаты и для каждого отдельного поддомена
Лучше не надо, так как это раскрывает состав кластера через публичные certificate transparency логи.
Благодарю за ценное замечание!
Я, скорее, имел в виду в данном контексте не внутренние сервисы, а публичные. Бывает всякое. Решение моё работает и для публичных сервисов. Не всегда админы, особенно в большой организации со строгими правилами, позволяют всем командам использовать wildcard-сертификаты: у каждого продукта должен быть отдельный сертификат.
Но для внутренних сервисов полностью согласен.
Статья на Хабре про эту технологию для интересующихся: Обзор Certificate Transparency.
Интересно, я бы про такое не подумал. Но это решается довольно просто - делается 1 технический поддомен типа infra.domain.com и вайлдкард делается на него, а там уже плодятся всякие srv1.infra.domain.com и т. п.
ExternalDNS не пробовали?
https://github.com/kubernetes-sigs/external-dns
Я кратко ознакомился с его описанием по Вашей наводке, но не понял, как его можно использовать для решения моей проблемы? Можете прокомментировать более подробно свою мысль?
ExternalDNS может работать в связке с cert-manager и создавать DNS-записи для проверки Let's Encrypt (_acme-challenge). Но Яндекс.Коннект как провайдер не поддерживается, увы.
Скорее всего, Вы неправы.
cert-manager не умеет работать в связке с ExternalDNS. Его нет в списке интеграций, но есть до сих пор открытое issue на тему интеграции.
Из этого issue я узнал, что ExternalDNS не умеет работать с TXT записями (только A и CNAME): issue.
Концепция ExternalDNS, если я понял её правильно, состоит в следующем: у вас есть сайты, которые нужно выставить наружу, вам лень (или сайтов очень много) прописывать для них DNS-записи руками, вы ставите ExternalDNS, который сканирует ваши ingress-ресурсы, берёт из них адреса сайтов и создаёт для них DNS-записи. Эта проблема (автоматическое создание DNS-записей) находится вне рамок данной статьи. Более того, задача как раз не публиковать в публичную Сеть внутренние сайты (тогда можно было бы вообще HTTP-01 обойтись). Даже если считать, что DNS-записи будут создаваться во внутреннем DNS, всё равно это не является темой данной статьи.
В целом, да, ExternalDNS — не бесполезный проект, можно найти ему применение, но к теме статьи имеет лишь косвенное отношение.
Wildcard-сертификат Let's Encrypt для внутренних сервисов в Kubernetes-кластере