ZeroSSL существует

Зачем тебе сертификаты для разработки?

Кудесник О_о

:) вот из-за таких как ты и ввели ограничение на 5 сертификатов :) сюрприз

https://letsencrypt.org/docs/staging-environment/

У него стоит ограничение на 5 сертификатов в неделю для определенного имени.

А нужно - 1 раз в 3 месяца. То есть и так на случай ошибок дали 60-кратный лимит от нужного. Для тестирования у них есть отдельный демо-урл без лимитов.

Это невалидный сертификат, мимо.

Ну ты и отжёг )) Я бы на месте LE тебя бы забанил за такое.

Ага, отлично

Restricted Countries

Currently, secure certificates of any type cannot be issued to individuals or business entities in the following countries, websites, or the following country-code-top-level domains (TLDs):

.ru The Russian Federation

These countries and TLDs are restricted by US Export restriction laws.

Не удивлюсь, что если узнают, что у владельца адрес российский или способ оплаты связан с БСРФ, не дадут/отзовут сертификат и на любой другой tld.

Прикольно, не знал, ну да, тогда не вариант для россиян, сорри.

А по уму надо сертификаты раскатывать через CMS или просто держать на балансировщике. Но «инженеры» после курсов «стань девопсом за неделю и начни зарабатывать миллионы» про это не в курсе, видимо.

Это невалидный девелопер, ссаными тряпками его из профессии

CMS к этому какое отношение имеет?

Нафига тебе валидный сертификат в процессе разработки и тестирования?

Потому, что альтернативы хуже.

Вот простой пример. Попробуй его написать по-другому.

  initContainers:
    - name: wait-for-start
      image: alpine
      command:
        - sh
        - -c
        - |
          while ! wget -q -O /dev/null https://keycloak.mysite.com/health/ready
          do
              sleep 10
          done
      securityContext:
        runAsUser: 65534

конечно без флага -k, жертвовать безопасностью из-за загонов letsencrypt-а неприемлемо.

И таких примеров миллион. Где-то придётся готовые контейнеры заменять на свои. Где-то придётся городить кучу конфигурации. Это плохой подход, создающий избыточную сложность на ровном месте.

жертвовать безопасностью из-за загонов letsencrypt-а неприемлемо.

У тебя в тестовом окружении MitMы водятся? Какую именно зловредную информацию они хотят пропихнуть в твой /dev/null?

Ну если у него там не только контейнеры то серты через нее растягивать по стейджингам, не?

А что мешает выписать вайлдкард на mysite.com и https://kubernetes.github.io/ingress-nginx/examples/tls-termination/ (ну или подкидывать во все контейнеры, если вы любители извращений)?

Я здесь вижу другую проблему: сделать -k только для тестового окружения это лишняя логика в шаблонах конфигов или вообще отдельные конфиги. С другой стороны, можно запилить вообще свой CA и его рутовый серт запхнуть в базовый образ, из которого строятся все остальные. Хотя подозреваю, что у ТС нет своего реджистри, и он втупую тянет вообще все с докерхаба какого.

просто хелм чарты накатывать по очереди с ожиданием а не городить такое убожество в инит контейнерах

Не понял вопроса. На вайлдкард-то такие же лимиты будут небось. Да и не хочу я использовать вайлдкард там, где это не нужно.

У меня есть набор скриптов и прочих ямлов, которые раскатывают кластер с нуля с кучкой сервисов. Сервисы порой друг к другу ходят по HTTPS, так они сделаны. Этот кластер я иногда разворачиваю на тестовом оборудовании, чтобы проверить, что это всё работает. А потом всё удаляю, чтобы деньги не тратить. На следующий день прихожу, продолжаю работу и опять разворачиваю. И так далее. И на проде он развернут. Когда я его разворачиваю с нуля, то он все сертификаты запрашивает заново, как и должно быть.

Сертификаты получаются через cert-manager, он сам их подкидывает в ингресс.

Когда я его разворачиваю с нуля, то он все сертификаты запрашивает заново, как и должно быть.

Нет, не должно. Просто представь, как бы ты работал с платным сертом.

Платный серт я бы вшил в образ и раз в год обновлял руками. С трёхмесячным летсенкриптом это не вариант.

не

Вот и купи себе платный серт и не страдай хернёй.

Зачем мне покупать платный серт, если есть бесплатный?

Обоснуй

Чтобы не заниматься творческим онанизмом с certbot’ом в каждом контейнере.

в том числе и генерируются сертификаты.
Понятно, что когда идёт разработка, то в этот лимит упираешься быстро.
Понятно

Не понятно от слова совсем. До появления LE, вы «в разработке» по десять раз в неделю покупали серты?

О чём ты? cert-manager всё делает полностью автоматически и с нулевыми усилиями. Ты с кубернетесом не работал, видимо.

До появления LE я кластеры не проектировал. Кажется кубернетес тогда ещё и не придумали. До появления LE я бы на wosign бесплатно получил бы 3-годовой сертификат и зашил бы его в проект. Или на startssl годовой. Или купил бы годовой.

До появления LE я бы на wosign бесплатно получил бы 3-годовой сертификат и зашил бы его в проект. Или на startssl годовой. Или купил бы годовой.

так какого лешего вы от le требуете по десять раз на дню?

Если бы LE выдавал 3-годовой сертификат, я бы ничего не требовал. А 3-месячный зашивать уже не вариант. Они умудрились подобрать такой период, что с ним хочешь-не хочешь, приходится автоматизировать. А всех конкурентов задавили.

Ну и вводить совершенно идиотские лимиты этого я приветствовать тоже никак не могу. У этого лимита нет и не может быть никаких обоснований.

А 3-месячный зашивать уже не вариант.

Почему?

Они умудрились подобрать такой период, что с ним хочешь-не хочешь, приходится автоматизировать.

В чем проблема? У вас cron сломался?

Обосновать чего?
Что ты ахинею спорол и я тебе на это ответил «не»?

В чем конкретно ахинея?

Так чем тебя не устраивает https://cert-manager.io/docs/configuration/selfsigned/ ?

И те же вайлкарды?

Летэнкрпт же теперь в вайлдкарды умеет, нафига тебе столько сертов?

Во-первых очевидно, что на ваилкарды будет тот же лимит в 5 штук в неделю, я даже проверять не буду.

Во-вторых ваилдкарды мне избыточны.

Тем же, чем не устраивает staging. Слишком много телодвижений, чтобы всё заработало с невалидными сертификатами. Так-то можно вообще ничего не делать, куб сам какой-то самоподписанный серт подсовывает по 443 порту (там правда хост неправильный, но если плевать на безопасность, то с высокой колокольни и никак иначе).

Не не, зойчем нужно выпускать 10, 100, 1000 отдельных сертов если можно выпустить один вайлдкард?

Как можно юзать zero ssl, если там прямо написано «3 90-дневных сертификата» на бесплатном тарифе? Зачем так страдать?

Если вы выпускаете сертификат по несколько раз на дню, да еще и при разработке - что-то сделано не так.

В кубере же есть cert-manager который сам следит за сертификатами и запрашивает их, только если сертификат истекает. Чем не подходит?

Не не, зойчем нужно выпускать 10, 100, 1000 отдельных сертов если можно выпустить один вайлдкард?

Когда 1000 отдельных сертов надо будет выпустить, тогда задумаюсь о вайлдкарде. Пока не надо - вайлдкард не нужен.

Как можно юзать zero ssl, если там прямо написано «3 90-дневных сертификата» на бесплатном тарифе? Зачем так страдать?

Нет, там нет ограничений на бесплатном тарифе для ACME

Если вы выпускаете сертификат по несколько раз на дню, да еще и при разработке - что-то сделано не так.

Нет, всё сделано как надо. Весь кластер с нуля разворачивается одной командой. И этот процесс нужно время от времени проверять. Когда идёт активная разработка или тестирование инфрастуктурного кода, его приходится проверять чаще пяти раз в неделю.

В кубере же есть cert-manager который сам следит за сертификатами и запрашивает их, только если сертификат истекает. Чем не подходит?

Всем подходит, использую его, суперская штука. Пожалуй один из самых классных плюсов куба для меня. Только ради него с кубом стоит заморочиться.

Не удивлюсь, что если узнают, что у владельца адрес российский или способ оплаты связан с БСРФ, не дадут/отзовут сертификат и на любой другой tld.

На форуме пишут, что для бесплатных ничего ограничивать не будут. Если не будет информации, что домен принадлежит человеку или организации в санкционном списке.

Не, круто узнать, что есть какой-то новый сервис. Я просто всё равно не понял нафига.

Ну если вкратце.

Есть такая штука как кластер кубернетес.

Его сервисам иногда нужен валидный сертификат. Обычно не нужен, можно общаться внутри кластера через http, но иногда нужен. Так вот они написаны.

Этот кластер я разворачиваю определенными скриптами. То бишь у хостера есть опенстак, там ничего нет. Я пишу terraform apply . и через полчаса у хостера создаются виртуалки, балансировщики нагрузки, диски там всякие, устанавливается развернутый кластер, где запущены все сервисы. Я пишу terraform destroy . и этот кластер удаляется.

Кроме того эти скрипты работают инкрементально, т.е. можно, к примеру, добавить туда новый сервис или изменить версию или настройки текущего и при запуске они приведут кластер в нужное состояние. Ну в теории.

Это удобно в основном для тестирования. У меня есть продуктовый кластер, который, конечно, никто не удаляет и есть какое-то нетривиальное изменение. На продуктовом кластере его тестировать некомильфо. Поэтому я разворачиваю тестовый кластер с этим изменением и убеждаюсь, что оно работают. А потом удаляю, ибо я живу в бедной стране и работаю в бедной компании, держать постоянно запущенным тестовый кластер денег нет. Ну и вообще удобно, в принципе можно это всё и на локалхосте развернуть, пока такой нужды не было, но доработок там будет немного.

В процессе разворачивания эти самые злополучные сертификаты получаются от letsencrypt как часть процесса инсталляции. Просто создается ингресс и cert-manager выпускает на него сертификат.

Иногда бывает так, что я что-то меняю и оно перестаёт работать. Т.е. я развернул, а оно криво развернулось. А сертификат уже выпустился. Я исправляю и прогоняю всё с нуля, чтобы убедиться, что всё работает. И когда что-то сильно и часто меняется, то такая ситуация можно произойти чаще, чем 5 раз в неделю.

У letsencrypt есть некоторые ограничения. В основном они все разумные. Но есть одно, которое мне мешает.

Сертификат обычно выпускается для одного домена. Но в общем случае в нём можно перечислить несколько доменов. letsencrypt для каждого домена просит доказать его владение и выпускает такой сертификат.

И вот для множества (domain1, domain2, …, domainN) существует ограничение в 5 сертификатов в неделю. Т.е. я могу выпустить 5 сертификатов на s1.mysite.com, а 6 уже не смогу. Но я могу поменять список доменов на (s1.mysite.com, s1-temp1.mysite.com) и выпустить ещё 5. Потом выпустить ещё 5 на (s1.mysite.com, s1-temp2.mysite.com). И так далее. В конце концов я упрусь в какой-то следующий лимит, наверное, но это мне не важно, там уже лимиты большие. Мне важно то, что этот лимит на 5 в неделю - он абсолютно глупый, он легко обходится (но не легко для меня, т.к. у меня конфиги статические и приходится руками добавлять эти мусорные домены) и он мне мешает. Собственно я так и делал, когда упирался в этот лимит - добавлял руками мусорные домены. В принципе если хорошо заморочиться, можно и генерировать этот мусорный домен, но блин, это же полная лажа.

Ну а zerossl можно использовать вместо letsencrypt путём нехитрых манипуляций (надо зарегистрироваться у них на сайте, получить api ключ и прописать его в настройках cert-manager) и по их обещаниям никаких лимитов нет. Поэтому прописав для тестового кластера этот самый zerossl я всю проблему снял малой кровью на мой взгляд. Попутно узнав, что не одним letsencrypt-ом живёт мир бесплатных сертификатов (и с сожалением узнав. что для ru доменов, похоже, одним, но у меня домен не ru, поэтому для меня это ограничение не такое уж критичное, хотя я всё же в проде оставлю letsencrypt).

Чтобы использовать невалидные сертификаты (самоподписанные или выпущенные через letsencrypt-staging), мне придется ощутимо перерабатывать многие скрипты, создавать свои образы вместо использования готовых. То бишь сейчас я использую какой-нибудь hashicorp/terraform, который собирают эти самые хашкорпы, а мне надо будет создавать новый репозиторий, писать докерфайл, в котором прописывать добавление staging root сертификата в этот образ, настраивать CI, чтобы он мониторил появление новых версий от хашкорпа и ребилдил этот доморощенный образ, прописывать в тестовую конфигурацию этот изменённый образ. И делать это для более, чем одного сервиса. Рискуя, между прочим, тем, что кто-нибудь перепутает эти сервисы и на прод задеплоит образ с тестовыми сертификатами в доверенных. А это как бы нехорошо, не могу сформулировать точно, почему, но вот чувствую, что нехорошо. Ну и вообще куча работы. А я как бы не девопс какой, у меня других дел хватает, чем заниматься какой-то левой работой, от которой только вред потенциальный.

А ваилдкард выпускать вместо отдельных на поддомены - в данной ситуации ничего не изменит. Вообще ваилдкард обычно нужен, если у тебя сервис, где выделяется поддомен на юзера или что-то похожее. Типа abcd-1234.ngrok.io. Вот тут точно упрёшься во все лимиты, если захочешь выпустить тысячу сертификатов, по одному на юзера. Тут уместен wildcard.

Ладно, я все равно не понял чем отдельные s1.mysite.com, s1-temp1.mysite.com лучше чем *.mysite.com.

Ладно, я все равно не понял чем отдельные s1.mysite.com, s1-temp1.mysite.com лучше чем *.mysite.com.

Вы не поняли, «это другое», как же на очередном «митапе» не пообсуждать и самое главное доказать, что «видите какой я полезный, столько я сделал?» :) Тут главное не результат, а сам процесс :)
Вот выпустите вы один раз wildcard... и всё, про вас забудут! :) Нафиг нам нужен Вася Печенькин ? Не нужен. А так каждый раз подтверждаем свою нужность. :)

сертификаты раскатывать через CMS

В этом, CMS никакого отношения к сертификатам не имеет и не должно иметь.

Иногда бывает так, что я что-то меняю и оно перестаёт работать.
И когда что-то сильно и часто меняется, то такая ситуация можно произойти чаще, чем 5 раз в неделю.

Кто пустил уборщицу в серверную?