Запускать несколько Executor'ов (Runner'ов) тоже не обязвтельно.
При исполнении задач CI есть возможность указать namespace/sa-bearer-token для запуска пода с задачей. И вот к этому sa-bearer-token можно привязать необходимыя для werf права.
Есть довольно несложное решение на базе acmetool. Общая идея в том, что в момент запроса сертификата, acmetool изображает из себя http сервер, а в nginx по известному url на default сервер стоит прокси в acmetool.
Поэтому автонастройка https в nginx происходит в 3 шага:
1) прописываем cname на хост с nginx+acmetool
2) через acmetool запрашиваем сертификат. При правильно настроеном пробросе, запрос по ненастроеному (пока) домену провалится в acmetool,
проходит авторизацию, и выданный сертификат кладетс в заранее известное место.
3) Из темплейта генерим конфиг сервера для nginx и делаем рестарт — все.
Еще 2 момента:
1) в уже настроеном конфиге все равно надо оставить прокси на acmetool для
автоматического обновления сертификатов (у меня вообще на 80-м порту никого нет, потому оно так и проваливается по default)
2) Прописать acmetool в cron — он сам проверяет, надо ли обновить сертификаты, и сам же обновляет.
Если есть интерес, могу завтра выложить соответствующие куски из своего ansible playbook
Попробовать безусловно стоит. Но конкретно в данном случае мне требовалось обновить отдельно стоящую ноду, к. нужен доступ внутрь работающего кластера. Можно было, конечно, сделать по кошерному с weave proxy, но хотелось понять, можно ли использовать решение с подменой моста и дальше. Оказалось таки можно
Т.е. банк подтверждает, что несмотря на то, что сессии подписаны его сертификатом, он не гарантирует достоверность данных переданных в этой сессии?
А зачем тогда вообще вся эта морока с сертификатами, если они _по определению_ не гарантируют достоверность и владелец ключа не отвечает за содержимое подписанных им сессий?
Вообще-то, статья о том, что можно в сессию вставить два TMITM-proxy да так, что рядовой юзер и не заметит…
Именно, и тут я полностью согласен. Вопрос только считать CF как TMITM или как end-point. СF декларирует свою услугу как end-point.
А уж доверять им или нет — каждый сам себе буратино.
Для определенности будем считать, что в нашем гипотетическом случае всё действует по законо «как оно должно быть», иначе смысл во всей этой возни с сертификатами теряется.
Особенно с учетом того, что ломать вас будут явно не во время вашего соединения с банком. Самый простой вариант — вашу сессию перехватили и мониторят, вы работу закончили, нажали «Logout», вам страничку Logout'а показали (но с прокси) — и понеслось…
Существует возможность перехвата активной SSL сессии? В чем тогда вообще смысл шифрования трафика? Ладно. Допустим.
Что будете предъявлять? Подписанные и проштампованные распечатки скриншотов дампов всего трафика с прошлой недели?
Да, я гипотетический параноик и пишу весь трафик за последний год и потащу в суд дамп с отпечатком ключа банка и поддельной страницы Logout.
Так что теперь вместо одного элемента нужно защищать как минимум два. И как минимум над одним из них банк не имеет контроля и значит, скорее всего, «ответственности не несет».
Т.е. банк открытым текстом говорит — «да, мы подписали вашу сессию с вот этим сервером, но мы не знаем, что там на сервере и знать не хотим»? И кто после этого останется в клиентах этого банка? Даже если юридически придраться невозможно.
А вообще, изначальный смысл моего комментария заключался в том, что я хотел акцентировать, что в предложенная CF схема лучше традиционной схемы фермы HTTPS-фронтендов, где каждый фронтенд имеет свою копию приватного ключа и сам пописывает все сессии. И тут, в случае взлома одного из фронтендов, получается полная свобода — есть приватный ключ и можно развлекаться. А здесь надо еще дополнительно обмануть и центральный подписывающий сервер.
Юридически сертификат на SSL-соединении ничего не значит. Банк может компенсировать всё, чтобы не терять репутацию, но при желании может от вас отмахнуться. С чем вы пойдёте в суд? Со словами, что выходили на сайт с подписанным соединением? А банк скажет — я это соединение не видел со своей стороны. Потребуется расследование и если найдут виновника, он вам возместит ущерб, если сможет.
Т.е. вы считаете, что банк соединение подписал, но ответственности не несет? Это как? Я не специалист в юрисдикции, но здравый смысл подсказывает, что тут что-то не так.
А вообще, естественно, 100% надежных систем не бывает. Вопрос только в количестве усилий необходимых для преодоления защиты.
Дайте мне тот банк, что не глядя подписывает все бумаги! :)
А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк. Печать банка стоит? Стоит.
Банк несет ответственность.
А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер. Навскидку могу предложить статический реверс-прокси в read-only докере и VPN по бронированому кабелю до банка. Даже если удастся получить доступ к файловой системе контейнера, злоумышленнику это ничего не даст. Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.
Каждое входящее соединение в CloudFlare передается в банк для подписи. Банк уже решает, что с ним делать. В какой-то степени это уже контроль.
Т.е. банк своей подписью подверждает свою ответственность за контент.
Да, разумеется. Естественно, остается вопрос доверия собственно серверам CloudFlare.
Но прелесть Keyless SSL в том, что на frontend HTTPS серверах _нет_ приватных ключей.
Что сильно уменьшает риск из утечки.
Вообще-то идея CloudFlare немного в другом. Традиционно, для организации SSL соединения требуется, чтобы на сервере присутствовал приватный ключ сертификата. И этот ключ используется только во время установления сессии и генерации временных ключей шифрования, которые в дальнейщем используются. Так вот ребята из CloudFlare предложили не хранить приавтные ключи на своих серверах, а передавать начальный зашифрованный handshake на специальный сервер заказчика для дешифровки/шифровки. Таким образом приватный ключ никогда не покидает сервер заказчика и позволяет масштабировать SSL фронтенды в облаке без передачи приватного ключа в облако.
Запускать несколько Executor'ов (Runner'ов) тоже не обязвтельно.
При исполнении задач CI есть возможность указать namespace/sa-bearer-token для запуска пода с задачей. И вот к этому sa-bearer-token можно привязать необходимыя для werf права.
См. подробнее
Не страшно давать контейнеру с Werf права cluster-admin на весь кластер?
Может хотя бы ограничить каким-либо namespace?
С gRPC API прекрасно работает Kong API Gateway
Поэтому автонастройка https в nginx происходит в 3 шага:
1) прописываем cname на хост с nginx+acmetool
2) через acmetool запрашиваем сертификат. При правильно настроеном пробросе, запрос по ненастроеному (пока) домену провалится в acmetool,
проходит авторизацию, и выданный сертификат кладетс в заранее известное место.
3) Из темплейта генерим конфиг сервера для nginx и делаем рестарт — все.
Еще 2 момента:
1) в уже настроеном конфиге все равно надо оставить прокси на acmetool для
автоматического обновления сертификатов (у меня вообще на 80-м порту никого нет, потому оно так и проваливается по default)
2) Прописать acmetool в cron — он сам проверяет, надо ли обновить сертификаты, и сам же обновляет.
Если есть интерес, могу завтра выложить соответствующие куски из своего ansible playbook
А зачем тогда вообще вся эта морока с сертификатами, если они _по определению_ не гарантируют достоверность и владелец ключа не отвечает за содержимое подписанных им сессий?
С 10-м еще не пробовал.
Или банк и этот процесс не контролирует?
Именно, и тут я полностью согласен. Вопрос только считать CF как TMITM или как end-point. СF декларирует свою услугу как end-point.
А уж доверять им или нет — каждый сам себе буратино.
Существует возможность перехвата активной SSL сессии? В чем тогда вообще смысл шифрования трафика? Ладно. Допустим.
Да, я гипотетический параноик и пишу весь трафик за последний год и потащу в суд дамп с отпечатком ключа банка и поддельной страницы Logout.
Т.е. банк открытым текстом говорит — «да, мы подписали вашу сессию с вот этим сервером, но мы не знаем, что там на сервере и знать не хотим»? И кто после этого останется в клиентах этого банка? Даже если юридически придраться невозможно.
А вообще, изначальный смысл моего комментария заключался в том, что я хотел акцентировать, что в предложенная CF схема лучше традиционной схемы фермы HTTPS-фронтендов, где каждый фронтенд имеет свою копию приватного ключа и сам пописывает все сессии. И тут, в случае взлома одного из фронтендов, получается полная свобода — есть приватный ключ и можно развлекаться. А здесь надо еще дополнительно обмануть и центральный подписывающий сервер.
Т.е. вы считаете, что банк соединение подписал, но ответственности не несет? Это как? Я не специалист в юрисдикции, но здравый смысл подсказывает, что тут что-то не так.
А вообще, естественно, 100% надежных систем не бывает. Вопрос только в количестве усилий необходимых для преодоления защиты.
А если серьезно, в этом случае мне, как клиенту, глубоко фиолетово, троян это на CF, или подломили сам банк. Печать банка стоит? Стоит.
Банк несет ответственность.
А вообще, обезопасить связку CF <-> банк гораздо проще, чем общедоступный HTTPS сервер. Навскидку могу предложить статический реверс-прокси в read-only докере и VPN по бронированому кабелю до банка. Даже если удастся получить доступ к файловой системе контейнера, злоумышленнику это ничего не даст. Посадить трояна он не сможет, прикинуться сервером CF тоже не сможет. Приватного ключа банка на сервере тоже нет. Тупик.
Т.е. банк своей подписью подверждает свою ответственность за контент.
Но прелесть Keyless SSL в том, что на frontend HTTPS серверах _нет_ приватных ключей.
Что сильно уменьшает риск из утечки.