У большинства популярных DNS-провайдеров есть API, с помощью которого можно управлять записями. Это позволяет автоматизировать заказ и продление SSL-сертификатов через DNS01.

В Kubernetes для работы с сертификатами используется cert-manager. Чтобы заказать сертификат в кластере, нужно объявить ресурс центра сертификации — например, ClusterIssuer, который используются для подписи CSR (запросов на выпуск сертификата). К сожалению, не для каждого DNS-провайдера существует CusterIssuer. Однако cert-manager позволяет написать свою реализацию. У нас такая потребность возникла в проекте одного из клиентов, который пользовался услугами DNS-провайдера REG.RU.

https://habr.com/ru/post/693858/?utm_source=habrahabr&utm_medium=rss&utm_campaign=693858

У вас есть кластер, в котором хочется разместить как можно больше рабочих сервисов и продуктов для внутреннего использования, ибо удобно: систему управления версиями, репозиторий Docker-образов, S3-хранилище, базы данных, тестовые среды и т.д. Но есть "но": многие из них, как например, репозиторий Docker-образов, могут работать только с использованием TLS. У вас есть два пути: получить сертификат от одного из сертификационных центров, платных или бесплатных, вроде Let's Encrypt, или сгенерировать самому. Устанавливать на каждого клиента сертификат нашего "левого" самопровозглашённого центра не хочется, поэтому самоподписанный сертификат отпадает. Денег платить каждый год не хочется, поэтому выбираем Let's Encrypt. Но и тут есть проблема (помимо необходимости автоматизации перевыпуска сертификата не реже раза в три месяца): внутренние сервисы нельзя выставлять в публичную сеть, а значит и HTTP-01 вариант подтверждения владения доменом нам недоступен. Остаётся только DNS-01 метод, который имеет свои подводные камни.

В данной статье я расскажу о своём опыте автоматизации выпуска/перевыпуска wildcard-сертификата для домена второго уровня (wildcard, чтобы два раза не вставать, но можно выпускать сертификаты и для каждого отдельного поддомена) для использования внутренними сервисами, расположенными в Kubernetes-кластере, с помощью cert-manager и бесплатного сервиса поддержки DNS-зон Яндекс.Коннект.

https://habr.com/ru/post/674738/?utm_source=habrahabr&utm_medium=rss&utm_campaign=674738

Я продолжаю цикл статей по приручению домашнего сервера разработчика, который хочет уметь в DevOps. В первой своей статье я рассказал о развёртывании Xen Project гипервизора и миграции Windows-виртуалок из Hyper-V. Во второй о развёртывании на базе виртуалок этого сервера Kubernetes-кластера. Перед написанием данной я ставил перед собой следующие цели:

1. Развернуть тестовый сайт, состоящий из статических ресурсов и front-end API в vanila Kubernetes-кластере.

2. Обеспечить доступ к этому сайту с использованием NGINX Ingress Controller.

3. Сайт должен быть доступен по HTTPS-протоколу с автоматически обновляемым TLS-сертификатом Let’s Encrypt.

https://habr.com/ru/post/668098/?utm_source=habrahabr&utm_medium=rss&utm_campaign=668098