Комментарии 78
На самом деле - нет, <…>
А точно нет? https://crt.sh/?q=habr.com
Хм... Спасибо!
Вы, конечно, тут правы.
Наверное, следует сделать апдейт ибо это значимая информация.
Я все же сделал ремарку со ссылкой на Вас по данному вопросу.
Ибо Вы абсолютно правы, хотя я и не вижу в этом действительно серьезных рисков.
Или нам понадобится dns-плагин к certbot, одна штука.
А еще права писать в зону и некоторые нюансы, с которыми людям приходится разбираться часами.
Но в принципе, конечно, да.
Предлагаю написать альтернативный пошаговый гайд, и пусть каждый выбирает для себя ;)
использую acme.sh пишу в соседнюю специальную зону которую держу на Cloudflare, на которую есть в основной одна не меняемая cname.
Зачем людям с чем-то разбираться?
Ну, мануал, который начинается с:
sudo apt-get install openssl jq curl git
Afterwards, change into the directory you want the tools located at and issue the following command:
git clone --recurse-submodules https://github.com/loewexy/pdns-acmeНу, знаете, такое. На любителя. Я не любитель.
Я предпочитаю сделать один раз так чтобы потом вот вообще не париться вообще ничем. Самое сложное при написании статьи было вспомнить где же точно вертится прокся ))))
Ну а на любой машине - install certbot, certbot run/certonly -d xxxx, ВСЕ )))
А, забыл еще systemctl enable --now certbot-renew.timer
Ну или просто галочка в интерфейсе "использовать летсенкрипт", в прикладе оно сейчас на каждом шагу.
На самом деле - нет, <…>
А точно нет? https://crt.sh/?q=habr.com
Split-DNS нормально работает только в "корпоративном концлагере", где все устройства тоже корпоративные, состоят в домене, с урезанными правами пользователей и пр. В схеме BYOD всё более популярный и кое-где уже зашитый по умолчанию DoH, да и просто разумное желание пользователя прописать DNS от Google или Cloudflare, сводят полезность такой конфигурации к нулю.
У меня просто внешний (он же единственный) DNS отдаёт для внутренних серверов внутренние же адреса. А сертификаты через DNS-плагин к certbot обновляются, да.
Между "кговагым ынтырпрайзом" и живопыркой на троих есть еще примерно весь спектр разного размера инфраструктур -- как виртуальных, так и не очень. Поэтому широко обобщать я бы не стал.
DNS-плагин это прекрасно, как и вайлкарды. Но парадокс в том, что в моей схеме все и всегда работает а) из коробки б) без бубна в) без кучи дополнительных условий.
Включая весь спектр софта, в который АСМЕ вшито, и далеко не всегда там под капотом именно Certbot, а и когда он - возможность им управлять зачастую неочевидна.
Я люблю простые решения, которые работают как калаш. С абсолютным минимумом условий и потенциальных нестыковок.
)
Простой вариант как калаш - один балансировщик-реверпрокси (тот же нжиникс или хапрокси или и то, и то - тут по вкусу) с терминацией ссл и вайлдкардами для нужных обслуживаемых доменов…
Кхм... У меня такое ощущение, что Вы не прочитали написанное мною или прочитали там что-то то свое.
Я вообще-то о внутренних ресурсах, предназначенных для внутренних пользователей (ну или пришедших через VPN, что одно и то же), и НЕ предназначенных для доступа из Интернета.
всё правильно, внутренние ресурсы, для внутренних пользователей.
и один балансировщик. с терминацией ссл. смотрящий наружу (одной ногой условно для www.domain.name) и запрашивающий вайлдкард *.domain.name. обращения к внутренним сервисам - через этот балансировщик, по уже внутренней ноге. одна точка терминации, один сертбот.
заодно внутренни сервисы принимают подключения только с одного внутреннего адреса (ну если делать ha - c нескольких) что упрощает фаерволенг и сегментирование сети.
в целом для внутренних клиентов обращаться по внешнему адресу тоже допустимо, но без настройки маршрутизации между внешними и внутренними адресами (например с полноценной DMZ и своей AS) - оно будет ну такое, на балансировщике внутренних адресов не увидите.
Все правильно, но есть нюанс: оправдано начиная с некоторого масштаба. Создает дополнительную точку отказа, куда сведены все приложения.
Немного повышает цену ошибки в том смысле что одно неверное движение - и вот все твои внутренние ресурсы немного опубликованы в Сеть.
Но концептуально идея зареверсить все внутренние ресурсы - понятная и по- своему богатая )))
В части получения сертификатов всё работает безусловно. А вот в части Split-DNS... подключается к нашей внутренней сети пользователь со своим смартфоном, в котором system-wide зашито использование DNS over HTTPS - и получает "внешние" адреса вместо внутренних. Далее одно из трёх. Либо мы такое вообще запрещаем, и тогда мы таки уже "кровавый энтерпрайз". Либо у нас нормально настроен доступ по внешним адресам из внутренней сети тоже (и тогда зачем нам в DNS внутренние адреса вообще). Либо как я предлагаю, раздавать внутренние адреса с внешнего DNS (особенно учитывая, что внешние адреса отнюдь не у всех серверов могут быть вообще, зачем они, прости Господи, какому-нибудь принтеру).
Кстати!
А что у нас за девайсы такие, которые возлагают болт на, допустим, профиль сети выданный им по DHCP и настойчиво используют DoH? Можно пару моделей? И что, это в принципе не лечится?
Ну так-то в принципе желание производителей смартфонов иметь покупателя всеобъемлюще - оно понятно. Другой вопрос что почти наверняка они будут криво работать не только в корпоративных сетях, но и во многих других случаях.
Почти все броузеры по дефолту пытаются так работать.
Мда?
У меня весьма свежий Андроид и винда, с которой я использую последние версии Хром, Вивальди, иногда - Оперу. Все обновляется до свежака.
Ни разу не сталкивался с ситуацией что где-то не работает DNS потому что вот оно хочет DoH и все.
ЧЯДНТ?
"я вот давеча медку поел и не зажужжал")
Уж не знаю сами далёкие от техники юзеры понажимали или оно так было дефолтно или они согласились "сделать безопасно", но не единичные проблемы у людей были. Притом кому-то хватало в hosts прописать нужный адрес, кому-то отключать... Ну и в будущем думаю вектор направлен на безопасность по аналогии с https и таких ситуаций будет всё больше.
Так что splitDNS будет иметь проблемы и в будущем их будет больше.
Это очень частные проблемы и по многим причинам поддержка старого доброго ДНС будет продолжаться еще долгие, долгие годы ;)
Вас не удивляет что сохранился SMTP, который старше уже очень многих читателей хабра? ;)
Потому что некоторые вещи очень живучи в силу своей простоты и отработанности.
https пришел на смену http очень даже быстро и очень принудительно, так что ещё пара-тройка лет...
Искренне прошу прощения, минуснул коммент промазав мышой, а отменить это нельзя (((
Есть огромная разница, сравните сами: DNSsec вроде бы существует чудовищное количество времени, а с распространением у него - проблемы. Потому что он весьма и весьма сложен.
HTTPS на самом деле не отдельный протоков, а очень простая комбинация HTTP и SSL/TLS и связанных с ним базовых библиотек.
И "поперло" его тогда, когда была разрешена проблема "невидимости" имени http-сервера в момент SSL-хэндшейка и массово появилась поддержка SNI. Ну и дальше тот же самый Летсенкрипт и другие, кто давал сертификаты бесплатно, сделали для его распространение.
C DNS ситуация другая: использовать TLS не стали, потому что так-то запрос-ответ - это UDP и два пакета, у TLS один хендшейк в разы больше требует - соответственно большие проблемы могут быть с таймингом рекурсивных запросов и еще много с чем. Сделали DNS-sec, но он оказался немного сложен "для среднего админа".
Ваше мнение о том, что DoH прямо быстро-быстро сменит DNS, кмк, основано на том, что его поддерживают большие корпорации для массово обслуживаемых ими клиентов. Но, к сожалению, есть еще и весь остальной мир ;)
Не страдаю кармой - так что пофиг)
Как мне кажется самую большую кучку в "популяризацию" положили броузеры с их манипуляцией "сайт является небезопасным" по поводу http [и неявным "а вот те жулики с https конечно же безопасны"].
А моё мнение базируется на том, что не большие корпорации, а опять же броузеры делают большую кнопку "сделать безопасно [не думая]", где среди этого безопасного в том числе и DoH + несколько крупняков.
Так что меня совсем не удивит если в очередном обновлении броузеров мелькнет в watsnew фраза "по умолчанию используется DoH, чтобы выключить закопайтесь в настройки". И собственно аудитория это вполне примет так же как и адресную строку, превратившуюся в поисковую (со всеми вариациями фишинга) и "зеленый замочек = безопасно"... не сильно вдаваясь в суть..
А заметили ли Вы парадокс, что уже много лет как броузеры взяли ОБРАТНЫЙ курс, перестав педалить тему "зеленый замочек - это безопасно" ;) ЕМНИП, сейчас уже многие и НЕ показывают "зеленую строку" когда сертификат выдан с полной авторизацией юрлица. Почему?
Да потому что пока ССЛ был уделом немногих - это было то, что позволяло дифференцировать "надежные ресурсы от ненадежных". С развитием раздачи халявных сертификатов - оказалось, что "зеленый замок" несет больше иллюзий, чем фактов - и его убрали.
Ну и не забывайте один момент: корпораты - это тоже существенная доля пользователей, а корпораты НИКОГДА не откажутся от закрытых внутренних инфраструктур. Поэтому броузеры всегда будут нормально их поддерживать, что бы там ни было.
От обратного: открываем любой ресурс по http и ловим страшную истерику про небезопасность
Открыл. Последним Хромом.
Никакой истерики кроме серенькой надписи "нот секуре" в адресной строке ;)
Сколько пришлось сделать дополнительных кликов?
Внезапно, ноль ;)
магия? махинация? localhost?
Самый свежий хром, дефолт в настройках, хотя и установлен весьма давно, зато постоянно обновлялся.
Да, у других броузеров все то же самое. Никто не истерит на как таковой http. Истерика начинается когда https с несовпадающим сертификатом, и тут уж как сконфигурировано в DNS и передавались ли строгие теги в успешных запросах раньше- от пары лишних кликов до полной невозможности соединения.
Любой Андроид, если на уровне девайса. Любой современный браузер, если на уровне браузера. В последнем случае оно ещё где-то и по умолчанию было, ЕМНИП, но и желание включить DoH вручную вполне объяснимо, если домашний или мобильный провайдер использует апстрим сервера НСДИ (а он-таки использует), выдающие вместо достоверных данных зацензурированное сами знаете что.
Дубль:
У меня весьма свежий Андроид и винда, с которой я использую последние версии Хром, Вивальди, иногда - Оперу. Все обновляется до свежака.
Ни разу не сталкивался с ситуацией что где-то не работает DNS потому что вот оно хочет DoH и все.
ЧЯДНТ?
Наверное, путаете ситуацию "оно хочет только DoH и не умеет использовать обычный DNS, полученный по DHCP" и ситуацию "оно не использует обычный DNS, полученный по DHCP, если в настройках включить DoH". А право пользователя включить этот самый DoH я понимаю, чту и уважаю, точно так же, как и его право использовать удобный ему почтовый клиент по IMAP, а не веб-интерфейс (из ветки комментов выше :)
Права пользователя заканчиваются там, где начинаются его обязанности ;) Это вообще-то базовый жизненный принцип трудовой деятельности )))
Концепция BYD, в моему понимании, заключается не в том, что пользователь делает что хочет и как ему удобно, а в том, что его устройство адаптируется ТАКЖЕ и под инфру работодателя - в разумных, но необходимых пределах.
Поэтому если пользователь начинает ныть "ой, у меня ваш випиен конфликтует с тем, через который я инстаграмчики листаю, вы не должны уважать мои желания", - то он логично идет... в Инстаграмм )))
Ну а так-то любому человеку работать неудобно. От работы кони дохнут, усталость и все такое )))
Поэтому если пользователь начинает ныть "ой, у меня ваш випиен конфликтует с тем, через который я инстаграмчики листаю, вы не должны уважать мои желания", - то он логично идет... в Инстаграмм )))
Мой корпоративный VPN (а в офисной сети и без VPN) просто позволяет и в Инстаграм ходить тоже :) Причём без ущерба хождению на российские сайты. Там вообще хитрая маршрутизация между 4 странами для минимизации ситуаций, когда хоть что-то не работает, поэтому пользователям нет смысла какими-то другими сервисами разной степени сомнительности пользоваться, что тоже позитивно сказывается на безопасности.
Отдавать наружу внутренние адреса чот ну такое. Мало того, что относительно публичны имена внутренних хостов, так ещё и ip их известны - а лучше отдавать наружу меньше инфы об инфраструктуре:)
Еще раз призываю прочитать и разобраться в сути ДО комментирования. Потому что никто наружу внутренние адреса не отдает и речь вообще про другое.
Есть такая мысль, но данный риск был сочтён минимальным. А решать проблему нормального доступа к внутренним сервисам с устройств с разными системными настройками DNS на уровне системы или браузера как-то надо было, в комменте выше по ветке расписал варианты, которые были.
Ну, главное что риск оценен, взвешен и принят :) к слову, тут ещё возможны косяки (в теории и отаки, но вы вероятно тоже учли) при работе без впн, когда можно попасть по имени куда-то совсем не туда - вплоть до отправки чуйствительной информации вроде паролей плейнтекстом-куков и т.п.
Я как чувак, что ближе к кровавому тыртырпрайзу предпочитаю сплитднс при отсутствии возможности/желания работать с внешними адресами сервисов или реверс-прокси (подробнее про нюансы отож писал выше).
Ну в детали вдаваться не буду, но про риски такие думал, моделировал. Может, что-то и пропустил, конечно. Но всё, что принимает чувствительные данные, таки имеет те самые сертификаты, в отсутствие которых софт ничего никуда не отправляет и матерно ругается. Ну и специфика работы (наличие сотрудников, которых самих и их устройства ни разу в жизни в глаза не видишь) особо на сохранность пароля рассчитывать не позволяет в любом случае, классический стикер с паролем на крышке ноута куда больший, и не особо управляемый риск :) А вот доступ в VPN уже изрядно параноидален - логин/пароль через LDAP + индивидуальные сертификаты + OTP + мониторинг новых устройств, в общем, для достаточно мелкой конторы, насколько я себя успокаиваю, хватает :)
Подумайте над имплементацией в том или ином формате подхода zero trust security. Условно нам не важно, где комп - в локалке (в впн) или дома, мы одинаково защищаем сервисы. Оно хорошо ложится на byod-подход и в целом не особо затратно можно сделать без накручивания conditional access и client posture/profiling.
Как вариант имплементации (не факт что подойдёт вам, чисто вариант концепта) сервисы вывешиваем на внешний адрес, но помимо аутентификации и авторизации через ldap крутим mfa, и проверяем наличие клиентского сертификата выданного внутренним СА. Сертификатом спасаемся от всяких zero-day, mfa - на случай если и учётка и серт утекут (например стырили ноут, а он нешифрован и пароль на рабочем столе). Можно использовать и совместно с впн, например mfa запрашивать только при внешнем подключении (тут понадобится опять же сплит/дмз, но по крайней мере часть сотрудников не будет страдать от mfa). Mfa хорошо крутить с sso вроде самл/oauth (в один сервис зашёл, в другие в период n часов влетаешь без запросов).
Оно всё прекрасно, но спотыкается о почту, которая в грубом приближении бывает или Exchange (у меня - нет, по разным причинам), или IMAP, к которому MFA и прочие прелести не прикручиваются от слова "совсем". Посему она и прячется за VPN (либо локальной сетью с WPA Entreprise), который является основным рубежом защиты.
А поскольку почта диктует именно такую модель, то и остальное по тому же принципу.
SAML / OAuth в планах есть, но это всё легко и ненапряжно поднимается с использованием Azure AD / Onelogin / Okta и прочих облачных сервисов, которые в один прекрасный момент стали не очень доступны к покупке без обходных путей, а рисковать использованием обходных путей, которые могут в любой момент отвалиться, не хотелось. А поднимать это полностью у себя задачка нетривиальная, начинал, отложил на потом :)
Да, оно красивое на бумажке, но требует осмысления, доработки и изменений. Тот же imap можно объявить легаси и похоронить в пользу вебинтерфейса условной зимбры. Или прикрутить к нему mtls (так же закрыть на серт клиентский)..
Если винда - с adfs тож не особо сложно. Больше проблем с сервисами, что или заводят для галочки поддержку, или начинают считать что это суперентерпрайзно и хотеть множество деняк:)
Простите, но "чтобы тебе с почтой только через веб-интерфейс работать" - звучит как проклятие ;)
Не надо трогать аймап, пожалуйста. Для почты ничего лучше не придумано и придумано в обозримом будущем не будет. Нравится нам это или нет.
Ну и не надо забывать что защита должна быть соразмерна угрозам, а кривую зависимости защищенности и удобства никто не отменял ;)
Классика же:
Сисадмин спросил Учителя:
– В статье написано, что любое усиление безопасности снижает лояльность работников. Это правда?
Инь Фу Во ответил:
– На самом деле усиление безопасности снижает удобство. Снижение удобства повышает усталость. Повышение усталости снижает добросовестность. А снижение добросовестности работников – это и есть то, чего следует избегать.
– Тогда что же такое лояльность? – спросил Сисадмин.
– "Лояльность", – усмехнулся Инь Фу Во, – это японцы выдумали, чтоб денег не платить.
Вот тут поддержу. Стараюсь не делать пользователям ничего, что мне самому было бы неудобно. А поменять свой Thunderbird с тремя десятками любовно отобранных расширений на веб-интерфейс - ну такое... В основном народ, конечно, так не заморачивается, но даже обычный десктопный Outlook на порядок удобнее любого веб-интерфейса.
Для конкретно thunderbird можно сделать плагин(нужно зашивать конкретные домены туда) для авторизации через oauth в dovecot. А oauth уже через keycloak и прочие штуки с MFA, отрубив нативные IMAP способы. Минус, что оно только для thunderbird
Ну и вообще - в гамаке на лыжах, все как мы любим )))))
Даже если всех перевести на Thunderbird (чего не хотелось бы, ибо у непродвинутых пользователей будет больше вопросов, им привычный Outlook из коробки проще), остаётся доступ с мобильных устройств, который не менее важен. В итоге работающая более или менее везде почта с MFA - это практически без вариантов только Exchange.
Делайте проще через DNS-01 challenge и делегирование CNAME для домена на сторонний домен. Например, для внутреннего домена и всех поддоменов *.secret.ru сделать запись:_acme-challenge.secret.ru CNAME _acme-challenge.publicdomain.ru
В записи _acme-challenge.publicdomain.ru сделать TXT со значением, который выдаст challenge.
Всё это дело упаковывается в скрипт, которому дать права на управление txt-записями доменам publicdomain.ru
В итоге у вас сертификат на все поддомены *.secret.ru, даже если к нему нет публичного доступа из вне (там конечно есть нюанс, что нужно будет указывать 2 домена при запросе сертификата: secret.ru и *.secret.ru, но wildcard поможет не светить все внутренности в логах crt.sh и подобных сканеров).
Ну по поводу "попроще" - это смело сказано! Там слова "скрипт" и "делегирование туда-сюда" и "дать права" прямо вопят о простоте реализации )))
Давайте сравним трудоемкость и, самое главное, вероятность ошибки для а) собрать всю схему и б) добавить еще одни сервер в) нигде ничего не поломать при изменениях
Кстати, забавный факт: я написал эту статью после того, как у одних моих, партнеров вдруг не смог зайти на один из их внутренних серверов - сертификат протух, а без него не пущает вообще - ибо запрещено. Ну, потрещали с админом - а там как раз Ваша схема - получает вайлдкард сертификат и потом скриптами разгоняет его по всем серверам. Все работало-работало, а потом нолик за единичку завалился, сертификат скрипт недослал на другой сервер. Ну и упс.
Это мы даже не говорим о примерно тыщще вариантов встройки ACME клиента в разный софт, где, конечно, можно и по Вашей схеме отработать, но обычно это требует отдельных танцев со специальными моделями бубнов ;)
Все работало-работало, а потом нолик за единичку завалился, сертификат скрипт недослал на другой сервер
Ну если никакой мониторинг по факту протухания сертификата не отсылает никакой алерт - то прозевать с одинаковым успехом можно и ошибку в работе централизованного скрипта (или плейбука Ansible, как в моём случае), и ошибку в обновлении сертификата с конкретного сервера.
Можно прозевать, да.
Но давайте поговорим о вероятностях. Чем сложнее и навороченнее схема, чем больше в ней кастомных скриптов, шагов и звеньев - тем больше вероятность возникновения проблемы при малейшем изменении условий.
Ну вот просто умозрительно, что имеет меньшую вероятность принести проблемы: тиражируемый софт, который запускается миллион раз в сутки по миру или самописный разлапистый скрипт, который даже протестировать толком на все возможные варианты раскладов нельзя - чисто по соображениям здравого смысла?
Лично я считаю, что с точки зрения практической надежности любюе решение через конфигурирование серийных продуктов штатными средствами даст огромную фору самопису любого генеза )))
Ну так "конфигурирование штатными средствами" в 2022 году, чай, тоже не заходом на каждый сервер ручками по SSH и редактированием конфигов в Vim осуществляется, а каким-нибудь Ansible...
Ну например в Проксмокс ты нажимаешь кнопку "получить сертификат". А, ну емейл надо указать.
Дело в том, что помимо Цертбота сейчас куча всяких приложений "из коробки" поддерживает ACME, там просто опция включается и все.
И да, кстати, чтобы тот же цертбот по моей схеме запустить с примерно 100% успехом - никаких редактирований конфига не требуется. Требуется 1(одна) команда на получение сертификата и 1(одна) на запуск таймера его обновления.
Как бы все.
Как альтернативу мне тут каждый первый предлагает набор скриптов. Кстати, надо будет спросить сколько примерно строк )))
В любом решении есть своя стоимость косяков)
Мы запилили внешний сервис, которому делегировали эти записи. Сервис сам выпускает и продлевает сертификаты и кладет их в хранилище. Клиент при сборке/запуске контейнера просто забирает актуальный сертификат, хоть каждые 5 минут со 100 нод одновременно. Обычный lets encrypt забанит за частный перевыпуск сертификата если вы его случайно потеряете.
Вопрос в масштабе. И выборе в соразмерного подхода.
Я прежде чем писать, почитал что понаписано в этих ваших энторнетах на эту тему. Была, в частности, шикарная статья про то, как раздавать Летсенктипт тысячами, сейчас не найду, но там смысл в динамическом одоменивании и так далее.
И да, если тебе надо много, если у тебя это важная часть процесса, то "запилили сервис" - это логично и правильно.
Но если у тебя еще примерно до пенсии не переделать разных других задач и надо раздать сертификаты на десяток-полтора хостов быстро, просто и надежно - то вот это как раз вариант, за час с нуля сделал и забыл про проблему навсегда )))
Поэтому мы оба правы в подходах, если, конечно, вы соразмерно подходите )))
А нет ли у вас конкретики о том, почему не подошел вариант "для своей сети поднимем свой CA и к нему прикрутим свой аналог LE"?
Это имеет смысл для достаточно большой компании, с способной содержать продвинутых админов и держать юзверей в крепком стойле, потому что:
Требует существенно большей квалификации на установку и настройку
Требует раскатки своего корневого сертификата в системы пользователей, в противном случай как минимум броузеры будут материться на невалидный серт, в наихудшем - не будут давать открывать ресурс вообще. Это легко сделать через всякие там полиси, но весьма геморройно руками.
Ну а у меня из серии "быстро, просто, доступно, не без недостатков, но за эти деньги...". Определенно это для НЕбольших компаний, и людей с НЕ слишком высокой квалификацией. Все максимально из-коробочно и прямолинейно.
Я конечно все понимаю, но зачем такой оверхед?
Я все сделал проще (для домашних серверов) есть vps, он получает wildcard *.mydomain.ru (при всем этом нам не обязательно в панели dns создавать поддомены на общее обозрение, внутренний dns справиться) и далее переправка безопасным туннелем на внутренний сервер, и с внутреннего сервера все это раскидывается по машинам и контейнерам. Профит. Валидные сертификаты в локалке, без своего уц которой все равно есть.
Кхм... Т.е. несколько десятков строк в файлах конфигурации из которых содержательных - менее десятка, а остальные - скобочки да отбивки - это оверхед.
А целый набор кастомных скриптов для получения, обновления, раскатывания по серверам, рестарта на этих серверах сервисов после раскатки, и все это с авторизацией, кстати, - это не оверхед а так, дунуть-плюнуть, да?
Нуууу ок. Рискну предположить, что скриптинг - Ваша сильная сторона, поэтому она и является для Вас простейшим путем. У меня, к сожалению, на такие вещи тупо нет времени.
И если уж так, то вариант с реверс-проксированием всех внутренних сервисов через один SSL-терминирующий прокси выглядит намного более вменяемым, простым и работоспособным.
Bash родной язык - это да, и не только он.
А городить конструкции с прокси сайтами докер контейнерами не оверхед? Круто конечно прийти на все готовое запустил контейнер пару строк поменял и все. Изначально было написано на bash был оверхед да. Нужно было ещё безопасное туннелирование делать для этого openvpn использовался. В текущей реализации написан софт он то и делает большую часть работы. Шифрует файлы, пихает в tls передает, расшифровывает, кидает по местам меняет права рестартует. Если нужно добавить сервер в цепочку нужно скомпилировать клиента с настройками что куда положить, что рестартануть и откуда взять. Импровизированный с&с сервер и клиенты
Дополню для авторизации на с&с используются УЦ, а все остальное что пытается стучатся на порт сервиса просто дропается, в принципе идея взята у openvpn с tls-crypt, при сканировании порт так же невидим, Профит.
Ну, если у вас внутри пасутся тучные стада стейтлесс контейнеров - тогда у вас своя атмосфера и все, написанное выше Вас не касается. Ну и Вы просто не целевая аудитория статьи ибо можете задачу из заголовка исполнить так, вот так, а еще под куполом на трапеции без страховки, и в гамаке на лыжах стоя )))
Я это писал для тех, у кого а) инфра довольно статична, а не буйство оркестрации б) ее сравнительно немного, а не многие десятки и сотни серверов в) у кого не так высока профильная квалификация и не так глубоко понимание ACME чтобы самому накатать решение.
Я не спорю что данное решение это плохо, или ещё что то. Нет, как вы сказали у всех свои потребности и задачи.
Например у меня дома две серверные железки обе на proxmox (включая Вирт для сборок). и резервная машина старый пк в качестве точки бекапа. + 2 vps разной мощности и задачи. Рабочих серверов 2+1. В итоге написал такой софт который решает проблемы с сертификатами, сделал его проприетарным для защиты в том числе. Ну и что бы на работе его потом не свиснули. Подписываю своим ключом от своего уц мне не напряжно держать на всех своих машинах свои корневые сертификаты, это же не от минцифры... а для рабочих машин подписываю их уц. В процессе версия 2, с большим фунционалом. Когда нибудь я напишу статьи об этом.
Ну, Вы начали про "слишком большой оверхед" )))
Я, напомню, констатировал, что здесь все решение, которое работает (не без недостатков!) занимает примерно час-два на все про все, после чего про него забываем вообще - есть другие задачи ))) И что как раз "оверхед" для средней руки админа здесь совершенно минимальный.
Вы рассказываете о своем подходе, реализация которого явно потребовала сотни человеко-часов. Который делает, конечно, все лучше и правильное ;)
Но вот по поводу "зачем такой оверхед? Я сделал все проще..." я по-прежнему не согласен. Вы сделали намного сложнее и более трудоемко в реализации, с другими слабыми местами и под свое видение.
Собственно весь предмет дискуссии только в этом.
Я не любитель использовать docker для чувствительной информации - это раз. Второе меньше чем за неделю была написана эта утилита изначально на с, в планах переписать на rust. И третье, ведь действительно если мало динамики контейнеры например сами не пересобираются, можно все было кинуть в bash скрипт и закинуть в cron (моя альфа версия так сказать), типо два скрипта сервер (где получаются сертификаты) и клиенты которые забирают сертификаты с сервера. Простым скриптом проверяем не истёк ли серт, если да то перевыпускаем, клиенты ходят на сервер по таймеру, видят что серт обновился забирают его раскидывают, а ночью рестарт сервисов.
В серверной утилите реализованно шифрование этого самого wildcard сертификата и ключа, и хранится он на сервере зашифрованным, в открытом виде на диске файл ключа вообще не появляется. Профильное образование по криптографии не прошло даром
Ну и навороты ))))
Вот я об этом и говорю: у вас решение "менее чем за неделю работы высококвалифицированного админа, хорошо умеющего в скрипты", у меня решение "менее чем за пару часов так себе админа".
Это просто разные истории.
Кстати, не имеет смысла шифровать сертификаты - они, вообще-то, в каждой ТЛС сессии отправляются. А закрытый ключ можно было бы раскатить по всем серверам один раз, если бы цертбот не генерировал его заново при каждом обновлении, что вовсе не является необходимым.
В общем, я думаю мы поняли друг друга)))
Не спорю все это делается банальным bash скриптом который сам прописывается при установке acme а дальше мелкий скрипт строк до 10 который будет на клиенте забирать по ssh серт.. быстро легко но не безопасно (проф паранойя) по этому все реализованно в изолированном участке ОЗУ внутри софта, получил зашифровал положил на диск.. Но это грубо говоря v.1.0, в v2 надеюсь прикрутить разворачивание серверов ты ей ssh ключ, выбрал что нужно и пошел отдыхать, в v.3 в планах прикрутить ко всему web оболочку и интегрировать zabbix. Планов много времени нет.
Спасибо за статью.
На nginx proxy manager смотрели в этом плане?
Не, и в голову не приходило. Но теперь посмотрел и скажу, что он про другое, он про то, как организовывать обращения снаружи в внутренним ресурсам, терминируя SSL на nginx.
Наверное это очень небесполезная штука для своих задач, но вряд ли можно им таки вот изящные конфигурации создавать, тут все же некоторое понимание нужно как нжинкс работает с запросами и почему так.
Ну и вообще я человек старорежимный, мне вот эти все нахлобучки на конфиги кажутся вряд ли нужными в пределах моих задач. За исключением OpenVPN, пожалуй, больно лень ее руками )))
Там не только про терминацию ssl , оно и сертификаты выдает и вся мощь nginx доступна.
Пользуем как раз для работы с внутренними сервисами + ssl от LE.
Достаточно NPM с помощью dns объяснить, что service.domain.name - это что-то с внутренним серым ip.
Для остальных в lan с помощью dns "сказать", что service.domain.name имеет локальный ip сервиса с NPM.
Публикации
Сертификаты Let's Encrypt и ACME вообще во внутренней сети