Ну, если у вас внутри пасутся тучные стада стейтлесс контейнеров - тогда у вас своя атмосфера и все, написанное выше Вас не касается. Ну и Вы просто не целевая аудитория статьи ибо можете задачу из заголовка исполнить так, вот так, а еще под куполом на трапеции без страховки, и в гамаке на лыжах стоя )))
Я это писал для тех, у кого а) инфра довольно статична, а не буйство оркестрации б) ее сравнительно немного, а не многие десятки и сотни серверов в) у кого не так высока профильная квалификация и не так глубоко понимание ACME чтобы самому накатать решение.
Искренне прошу прощения, минуснул коммент промазав мышой, а отменить это нельзя (((
Есть огромная разница, сравните сами: DNSsec вроде бы существует чудовищное количество времени, а с распространением у него - проблемы. Потому что он весьма и весьма сложен.
HTTPS на самом деле не отдельный протоков, а очень простая комбинация HTTP и SSL/TLS и связанных с ним базовых библиотек. И "поперло" его тогда, когда была разрешена проблема "невидимости" имени http-сервера в момент SSL-хэндшейка и массово появилась поддержка SNI. Ну и дальше тот же самый Летсенкрипт и другие, кто давал сертификаты бесплатно, сделали для его распространение.
C DNS ситуация другая: использовать TLS не стали, потому что так-то запрос-ответ - это UDP и два пакета, у TLS один хендшейк в разы больше требует - соответственно большие проблемы могут быть с таймингом рекурсивных запросов и еще много с чем. Сделали DNS-sec, но он оказался немного сложен "для среднего админа".
Ваше мнение о том, что DoH прямо быстро-быстро сменит DNS, кмк, основано на том, что его поддерживают большие корпорации для массово обслуживаемых ими клиентов. Но, к сожалению, есть еще и весь остальной мир ;)
Кхм... Т.е. несколько десятков строк в файлах конфигурации из которых содержательных - менее десятка, а остальные - скобочки да отбивки - это оверхед. А целый набор кастомных скриптов для получения, обновления, раскатывания по серверам, рестарта на этих серверах сервисов после раскатки, и все это с авторизацией, кстати, - это не оверхед а так, дунуть-плюнуть, да?
Нуууу ок. Рискну предположить, что скриптинг - Ваша сильная сторона, поэтому она и является для Вас простейшим путем. У меня, к сожалению, на такие вещи тупо нет времени.
И если уж так, то вариант с реверс-проксированием всех внутренних сервисов через один SSL-терминирующий прокси выглядит намного более вменяемым, простым и работоспособным.
Это очень частные проблемы и по многим причинам поддержка старого доброго ДНС будет продолжаться еще долгие, долгие годы ;) Вас не удивляет что сохранился SMTP, который старше уже очень многих читателей хабра? ;) Потому что некоторые вещи очень живучи в силу своей простоты и отработанности.
Ну, тут уж извините, такой вопрос где техника прямо взаимодействует с управлением и людьми. А вообще здорово когда технически возможно/нет и нет предмета для дискуссии )))
Права пользователя заканчиваются там, где начинаются его обязанности ;) Это вообще-то базовый жизненный принцип трудовой деятельности )))
Концепция BYD, в моему понимании, заключается не в том, что пользователь делает что хочет и как ему удобно, а в том, что его устройство адаптируется ТАКЖЕ и под инфру работодателя - в разумных, но необходимых пределах.
Поэтому если пользователь начинает ныть "ой, у меня ваш випиен конфликтует с тем, через который я инстаграмчики листаю, вы не должны уважать мои желания", - то он логично идет... в Инстаграмм )))
Ну а так-то любому человеку работать неудобно. От работы кони дохнут, усталость и все такое )))
Ну например в Проксмокс ты нажимаешь кнопку "получить сертификат". А, ну емейл надо указать. Дело в том, что помимо Цертбота сейчас куча всяких приложений "из коробки" поддерживает ACME, там просто опция включается и все. И да, кстати, чтобы тот же цертбот по моей схеме запустить с примерно 100% успехом - никаких редактирований конфига не требуется. Требуется 1(одна) команда на получение сертификата и 1(одна) на запуск таймера его обновления. Как бы все.
Как альтернативу мне тут каждый первый предлагает набор скриптов. Кстати, надо будет спросить сколько примерно строк )))
Простите, но "чтобы тебе с почтой только через веб-интерфейс работать" - звучит как проклятие ;) Не надо трогать аймап, пожалуйста. Для почты ничего лучше не придумано и придумано в обозримом будущем не будет. Нравится нам это или нет. Ну и не надо забывать что защита должна быть соразмерна угрозам, а кривую зависимости защищенности и удобства никто не отменял ;)
Классика же:
Сисадмин спросил Учителя: – В статье написано, что любое усиление безопасности снижает лояльность работников. Это правда?
Инь Фу Во ответил: – На самом деле усиление безопасности снижает удобство. Снижение удобства повышает усталость. Повышение усталости снижает добросовестность. А снижение добросовестности работников – это и есть то, чего следует избегать.
– Тогда что же такое лояльность? – спросил Сисадмин.
– "Лояльность", – усмехнулся Инь Фу Во, – это японцы выдумали, чтоб денег не платить.
Это имеет смысл для достаточно большой компании, с способной содержать продвинутых админов и держать юзверей в крепком стойле, потому что:
Требует существенно большей квалификации на установку и настройку
Требует раскатки своего корневого сертификата в системы пользователей, в противном случай как минимум броузеры будут материться на невалидный серт, в наихудшем - не будут давать открывать ресурс вообще. Это легко сделать через всякие там полиси, но весьма геморройно руками.
Ну а у меня из серии "быстро, просто, доступно, не без недостатков, но за эти деньги...". Определенно это для НЕбольших компаний, и людей с НЕ слишком высокой квалификацией. Все максимально из-коробочно и прямолинейно.
Кстати! А что у нас за девайсы такие, которые возлагают болт на, допустим, профиль сети выданный им по DHCP и настойчиво используют DoH? Можно пару моделей? И что, это в принципе не лечится? Ну так-то в принципе желание производителей смартфонов иметь покупателя всеобъемлюще - оно понятно. Другой вопрос что почти наверняка они будут криво работать не только в корпоративных сетях, но и во многих других случаях.
Все правильно, но есть нюанс: оправдано начиная с некоторого масштаба. Создает дополнительную точку отказа, куда сведены все приложения. Немного повышает цену ошибки в том смысле что одно неверное движение - и вот все твои внутренние ресурсы немного опубликованы в Сеть. Но концептуально идея зареверсить все внутренние ресурсы - понятная и по- своему богатая )))
Вопрос в масштабе. И выборе в соразмерного подхода.
Я прежде чем писать, почитал что понаписано в этих ваших энторнетах на эту тему. Была, в частности, шикарная статья про то, как раздавать Летсенктипт тысячами, сейчас не найду, но там смысл в динамическом одоменивании и так далее.
И да, если тебе надо много, если у тебя это важная часть процесса, то "запилили сервис" - это логично и правильно.
Но если у тебя еще примерно до пенсии не переделать разных других задач и надо раздать сертификаты на десяток-полтора хостов быстро, просто и надежно - то вот это как раз вариант, за час с нуля сделал и забыл про проблему навсегда )))
Поэтому мы оба правы в подходах, если, конечно, вы соразмерно подходите )))
Но давайте поговорим о вероятностях. Чем сложнее и навороченнее схема, чем больше в ней кастомных скриптов, шагов и звеньев - тем больше вероятность возникновения проблемы при малейшем изменении условий. Ну вот просто умозрительно, что имеет меньшую вероятность принести проблемы: тиражируемый софт, который запускается миллион раз в сутки по миру или самописный разлапистый скрипт, который даже протестировать толком на все возможные варианты раскладов нельзя - чисто по соображениям здравого смысла?
Лично я считаю, что с точки зрения практической надежности любюе решение через конфигурирование серийных продуктов штатными средствами даст огромную фору самопису любого генеза )))
Ну по поводу "попроще" - это смело сказано! Там слова "скрипт" и "делегирование туда-сюда" и "дать права" прямо вопят о простоте реализации )))
Давайте сравним трудоемкость и, самое главное, вероятность ошибки для а) собрать всю схему и б) добавить еще одни сервер в) нигде ничего не поломать при изменениях
Кстати, забавный факт: я написал эту статью после того, как у одних моих, партнеров вдруг не смог зайти на один из их внутренних серверов - сертификат протух, а без него не пущает вообще - ибо запрещено. Ну, потрещали с админом - а там как раз Ваша схема - получает вайлдкард сертификат и потом скриптами разгоняет его по всем серверам. Все работало-работало, а потом нолик за единичку завалился, сертификат скрипт недослал на другой сервер. Ну и упс.
Это мы даже не говорим о примерно тыщще вариантов встройки ACME клиента в разный софт, где, конечно, можно и по Вашей схеме отработать, но обычно это требует отдельных танцев со специальными моделями бубнов ;)
Кхм... У меня такое ощущение, что Вы не прочитали написанное мною или прочитали там что-то то свое. Я вообще-то о внутренних ресурсах, предназначенных для внутренних пользователей (ну или пришедших через VPN, что одно и то же), и НЕ предназначенных для доступа из Интернета.
Ну, если у вас внутри пасутся тучные стада стейтлесс контейнеров - тогда у вас своя атмосфера и все, написанное выше Вас не касается. Ну и Вы просто не целевая аудитория статьи ибо можете задачу из заголовка исполнить так, вот так, а еще под куполом на трапеции без страховки, и в гамаке на лыжах стоя )))
Я это писал для тех, у кого а) инфра довольно статична, а не буйство оркестрации б) ее сравнительно немного, а не многие десятки и сотни серверов в) у кого не так высока профильная квалификация и не так глубоко понимание ACME чтобы самому накатать решение.
Искренне прошу прощения, минуснул коммент промазав мышой, а отменить это нельзя (((
Есть огромная разница, сравните сами: DNSsec вроде бы существует чудовищное количество времени, а с распространением у него - проблемы. Потому что он весьма и весьма сложен.
HTTPS на самом деле не отдельный протоков, а очень простая комбинация HTTP и SSL/TLS и связанных с ним базовых библиотек.
И "поперло" его тогда, когда была разрешена проблема "невидимости" имени http-сервера в момент SSL-хэндшейка и массово появилась поддержка SNI. Ну и дальше тот же самый Летсенкрипт и другие, кто давал сертификаты бесплатно, сделали для его распространение.
C DNS ситуация другая: использовать TLS не стали, потому что так-то запрос-ответ - это UDP и два пакета, у TLS один хендшейк в разы больше требует - соответственно большие проблемы могут быть с таймингом рекурсивных запросов и еще много с чем. Сделали DNS-sec, но он оказался немного сложен "для среднего админа".
Ваше мнение о том, что DoH прямо быстро-быстро сменит DNS, кмк, основано на том, что его поддерживают большие корпорации для массово обслуживаемых ими клиентов. Но, к сожалению, есть еще и весь остальной мир ;)
Кхм... Т.е. несколько десятков строк в файлах конфигурации из которых содержательных - менее десятка, а остальные - скобочки да отбивки - это оверхед.
А целый набор кастомных скриптов для получения, обновления, раскатывания по серверам, рестарта на этих серверах сервисов после раскатки, и все это с авторизацией, кстати, - это не оверхед а так, дунуть-плюнуть, да?
Нуууу ок. Рискну предположить, что скриптинг - Ваша сильная сторона, поэтому она и является для Вас простейшим путем. У меня, к сожалению, на такие вещи тупо нет времени.
И если уж так, то вариант с реверс-проксированием всех внутренних сервисов через один SSL-терминирующий прокси выглядит намного более вменяемым, простым и работоспособным.
Ну и вообще - в гамаке на лыжах, все как мы любим )))))
Это очень частные проблемы и по многим причинам поддержка старого доброго ДНС будет продолжаться еще долгие, долгие годы ;)
Вас не удивляет что сохранился SMTP, который старше уже очень многих читателей хабра? ;)
Потому что некоторые вещи очень живучи в силу своей простоты и отработанности.
Ну, тут уж извините, такой вопрос где техника прямо взаимодействует с управлением и людьми.
А вообще здорово когда технически возможно/нет и нет предмета для дискуссии )))
Про инстаграм - это был пример ;)
Я так понимаю, что сам тезис возражений все же не вызывает? )))
Права пользователя заканчиваются там, где начинаются его обязанности ;) Это вообще-то базовый жизненный принцип трудовой деятельности )))
Концепция BYD, в моему понимании, заключается не в том, что пользователь делает что хочет и как ему удобно, а в том, что его устройство адаптируется ТАКЖЕ и под инфру работодателя - в разумных, но необходимых пределах.
Поэтому если пользователь начинает ныть "ой, у меня ваш випиен конфликтует с тем, через который я инстаграмчики листаю, вы не должны уважать мои желания", - то он логично идет... в Инстаграмм )))
Ну а так-то любому человеку работать неудобно. От работы кони дохнут, усталость и все такое )))
Дубль:
У меня весьма свежий Андроид и винда, с которой я использую последние версии Хром, Вивальди, иногда - Оперу. Все обновляется до свежака.
Ни разу не сталкивался с ситуацией что где-то не работает DNS потому что вот оно хочет DoH и все.
ЧЯДНТ?
Ну например в Проксмокс ты нажимаешь кнопку "получить сертификат". А, ну емейл надо указать.
Дело в том, что помимо Цертбота сейчас куча всяких приложений "из коробки" поддерживает ACME, там просто опция включается и все.
И да, кстати, чтобы тот же цертбот по моей схеме запустить с примерно 100% успехом - никаких редактирований конфига не требуется. Требуется 1(одна) команда на получение сертификата и 1(одна) на запуск таймера его обновления.
Как бы все.
Как альтернативу мне тут каждый первый предлагает набор скриптов. Кстати, надо будет спросить сколько примерно строк )))
Мда?
У меня весьма свежий Андроид и винда, с которой я использую последние версии Хром, Вивальди, иногда - Оперу. Все обновляется до свежака.
Ни разу не сталкивался с ситуацией что где-то не работает DNS потому что вот оно хочет DoH и все.
ЧЯДНТ?
Простите, но "чтобы тебе с почтой только через веб-интерфейс работать" - звучит как проклятие ;)
Не надо трогать аймап, пожалуйста. Для почты ничего лучше не придумано и придумано в обозримом будущем не будет. Нравится нам это или нет.
Ну и не надо забывать что защита должна быть соразмерна угрозам, а кривую зависимости защищенности и удобства никто не отменял ;)
Классика же:
Сисадмин спросил Учителя:
– В статье написано, что любое усиление безопасности снижает лояльность работников. Это правда?
Инь Фу Во ответил:
– На самом деле усиление безопасности снижает удобство. Снижение удобства повышает усталость. Повышение усталости снижает добросовестность. А снижение добросовестности работников – это и есть то, чего следует избегать.
– Тогда что же такое лояльность? – спросил Сисадмин.
– "Лояльность", – усмехнулся Инь Фу Во, – это японцы выдумали, чтоб денег не платить.
Это имеет смысл для достаточно большой компании, с способной содержать продвинутых админов и держать юзверей в крепком стойле, потому что:
Требует существенно большей квалификации на установку и настройку
Требует раскатки своего корневого сертификата в системы пользователей, в противном случай как минимум броузеры будут материться на невалидный серт, в наихудшем - не будут давать открывать ресурс вообще. Это легко сделать через всякие там полиси, но весьма геморройно руками.
Ну а у меня из серии "быстро, просто, доступно, не без недостатков, но за эти деньги...". Определенно это для НЕбольших компаний, и людей с НЕ слишком высокой квалификацией. Все максимально из-коробочно и прямолинейно.
Кстати!
А что у нас за девайсы такие, которые возлагают болт на, допустим, профиль сети выданный им по DHCP и настойчиво используют DoH? Можно пару моделей? И что, это в принципе не лечится?
Ну так-то в принципе желание производителей смартфонов иметь покупателя всеобъемлюще - оно понятно. Другой вопрос что почти наверняка они будут криво работать не только в корпоративных сетях, но и во многих других случаях.
Все правильно, но есть нюанс: оправдано начиная с некоторого масштаба. Создает дополнительную точку отказа, куда сведены все приложения.
Немного повышает цену ошибки в том смысле что одно неверное движение - и вот все твои внутренние ресурсы немного опубликованы в Сеть.
Но концептуально идея зареверсить все внутренние ресурсы - понятная и по- своему богатая )))
Вопрос в масштабе. И выборе в соразмерного подхода.
Я прежде чем писать, почитал что понаписано в этих ваших энторнетах на эту тему. Была, в частности, шикарная статья про то, как раздавать Летсенктипт тысячами, сейчас не найду, но там смысл в динамическом одоменивании и так далее.
И да, если тебе надо много, если у тебя это важная часть процесса, то "запилили сервис" - это логично и правильно.
Но если у тебя еще примерно до пенсии не переделать разных других задач и надо раздать сертификаты на десяток-полтора хостов быстро, просто и надежно - то вот это как раз вариант, за час с нуля сделал и забыл про проблему навсегда )))
Поэтому мы оба правы в подходах, если, конечно, вы соразмерно подходите )))
Можно прозевать, да.
Но давайте поговорим о вероятностях. Чем сложнее и навороченнее схема, чем больше в ней кастомных скриптов, шагов и звеньев - тем больше вероятность возникновения проблемы при малейшем изменении условий.
Ну вот просто умозрительно, что имеет меньшую вероятность принести проблемы: тиражируемый софт, который запускается миллион раз в сутки по миру или самописный разлапистый скрипт, который даже протестировать толком на все возможные варианты раскладов нельзя - чисто по соображениям здравого смысла?
Лично я считаю, что с точки зрения практической надежности любюе решение через конфигурирование серийных продуктов штатными средствами даст огромную фору самопису любого генеза )))
Ну по поводу "попроще" - это смело сказано! Там слова "скрипт" и "делегирование туда-сюда" и "дать права" прямо вопят о простоте реализации )))
Давайте сравним трудоемкость и, самое главное, вероятность ошибки для а) собрать всю схему и б) добавить еще одни сервер в) нигде ничего не поломать при изменениях
Кстати, забавный факт: я написал эту статью после того, как у одних моих, партнеров вдруг не смог зайти на один из их внутренних серверов - сертификат протух, а без него не пущает вообще - ибо запрещено. Ну, потрещали с админом - а там как раз Ваша схема - получает вайлдкард сертификат и потом скриптами разгоняет его по всем серверам. Все работало-работало, а потом нолик за единичку завалился, сертификат скрипт недослал на другой сервер. Ну и упс.
Это мы даже не говорим о примерно тыщще вариантов встройки ACME клиента в разный софт, где, конечно, можно и по Вашей схеме отработать, но обычно это требует отдельных танцев со специальными моделями бубнов ;)
Еще раз призываю прочитать и разобраться в сути ДО комментирования. Потому что никто наружу внутренние адреса не отдает и речь вообще про другое.
Кхм... У меня такое ощущение, что Вы не прочитали написанное мною или прочитали там что-то то свое.
Я вообще-то о внутренних ресурсах, предназначенных для внутренних пользователей (ну или пришедших через VPN, что одно и то же), и НЕ предназначенных для доступа из Интернета.