У большинства популярных DNS-провайдеров есть API, с помощью которого можно управлять записями. Это позволяет автоматизировать заказ и продление SSL-сертификатов через DNS01.
В Kubernetes для работы с сертификатами используется cert-manager. Чтобы заказать сертификат в кластере, нужно объявить ресурс центра сертификации — например, ClusterIssuer, который используются для подписи CSR (запросов на выпуск сертификата). К сожалению, не для каждого DNS-провайдера существует CusterIssuer. Однако cert-manager позволяет написать свою реализацию. У нас такая потребность возникла в проекте одного из клиентов, который пользовался услугами DNS-провайдера REG.RU.
Изначально мы вручную заказывали сертификаты через acme.sh, складывали их в репозиторий, а затем деплоили в кластер. Нам это надоело, и мы решили автоматизировать процесс. Так появился инструмент ClusterIssuer для REG.RU. Рады представить его Open Source-сообществу!
Инструкция по использованию
Для начала убедитесь, что в кластере установлен cert-manager. Если его нет, установите согласно инструкции:
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.9.1/cert-manager.yaml
Затем клонируйте репозиторий с ClusterIssuer:
git clone https://github.com/flant/clusterissuer-regru.git
Отредактируйте в нём файл values.yaml
, заполнив поля zone
, image
, user
и password
. Например:
issuer:
zone: my-domain-test.ru
image: ghcr.io/flant/cluster-issuer-regru:1.0.0
user: my_user@example.com
password: my_password
где user
и password
— данные для аутентификации в системе REG.RU.
Установите вебхук. Перейдите в каталог репозитория:
cd clusterissuer-regru
Выполните команду:
helm install -n cert-manager regru-webhook ./helm
Создайте файл ClusterIssuer.yaml
с таким содержимым (но не забудьте заменить e-mail на свой!):
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: regru-dns
spec:
acme:
# Email address used for ACME registration. REPLACE THIS WITH YOUR EMAIL!
email: mail@example.com
# The ACME server URL
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: cert-manager-letsencrypt-private-key
solvers:
- dns01:
webhook:
config:
regruPasswordSecretRef:
name: regru-password
key: REGRU_PASSWORD
groupName: {{ .Values.groupName.name }}
solverName: regru-dns
Сохраните файл и выполните команду:
kubectl create -f ClusterIssuer.yaml
После этого можно создавать ресурс сертификата.
Пример: wildcard certificate
Создайте файл certificate.yaml
с таким содержимым:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: changeme
namespace: changeme
spec:
secretName: changeme
issuerRef:
name: regru-dns
kind: ClusterIssuer
dnsNames:
- *.my-domain-test.ru
Выполните команду:
kubectl create -f certificate.yaml
Выпуск сертификата может занять некоторое время (зависит от скорости распространения записи у провайдера по его серверам). После этого сертификат сразу же будет готов к использованию в вашем приложении.
Заключение
Если у вас есть какие-то идеи или пожелания по добавлению новых функций, приносите их в issues (или даже pull requests). И, конечно, будем рады новым звездам!
Исходный код проекта распространяется на условиях Apache License 2.0.
P.S.
Читайте также в нашем блоге:
Комментарии (5)
smesh
21.10.2022 15:57При наличии двухфакторной авторизации будет работать?
kmkuprienko Автор
21.10.2022 17:18Такой кейс мы не проверяли, но, если верить документации, наличие 2FA никак не должно мешать аутентификации в API.
Greenback
А в чем отличие от Letsencrypt?
vanxant
Буквы LE в названии статьи означают именно Lets Encrypt.
Смысл в том, что для обновления wildcard - сертификата LE нужно вносить специальные записи в dns-зону (для подтверждения, что вы ей владеете). Причём делать это приходится каждые три месяца. Для крупных буржуйских регистраторов есть скрипты, делающие красиво одной кнопкой, которые можно положить в крон и забыть. Ну вот и для посконного рег.ру появился.
kmkuprienko Автор
А что вы пытаетесь сравнить? Сертификат выписывается у того же Lets Encrypt. Если речь про ClusterIssuer на основе Lets Encrypt, то у него проверка только только по HTTP челенджу, а в нашем решении используется DNS челендж, так как домен находится в закрытом контуре. Кроме того мы выписываем wildcard-сертификат, что возможно только при использовании DNS челенджа.