Итого: мы не хотели хранить секреты в secrets kubernetes, и вместо этого использовали 2 других инструмента, чтобы ... в итоге хранить секреты в secrets kubernetes
тут сознательно упускается момент, что
абсолютно безопасную систему не построить
следствие - надо идти на компромиссы
аудит вольта - уже явно лучше аудита секретов в кубере
и если секрет утечет - его можно будет, условно, поменять "одной кнопкой" везде, а не бегать по 100500 секретов в 100500 кластеров, лихорадочно пытаясь понять - а что надо менять-то!
ну, и я ниже писал - надо от статических секретов уходить. Те же сертификаты с коротким сроком жизни (а vault умеет быть pki) или секреты одноразки - уже сильно сокращают поверхность атаки для злоумышленника. И тут сильно могут помочь средства раннего обнаружения атак. Очевидно, что если кто-то лазит по ФС контейнера с запросами вида `cat /proc/<pid>/environ` - это уже аномалия и нас уже ломают. А если секрет лежит в файле - ну, пойди отличи - легитимная ли это деятельность или нет.
1) Vault здесь используется как единый источник хранения секретов, таким образом нам не нужны секреты хранить в репозиториях (пусть даже с шифрованием в виде инструментов SOPS, helm secrets, etc...) - ведь если мы говорим о подходе IaC, что для нас немаловажно, то хранить даже секреты где-то нужно и чтобы это "где-то" - было единственным источником правды.
а это проблема, потому что автоматически влетаем в следующие вопросы
как мы будем вольт бекапить? Если нет другого золотого источника правды - ну, вольт им становится, значит нам нужно подходить к нему как к питомцу. Лелеять, лечить.
Vault автоматом становится критическим узлом на пути всего - деплоя, запуска и прочего. Вольт играет в поваляшки - инфраструктура начинает напоминать дорогущий чемодан без ручки. Следовательно, автоматом требования к HA, возможности обслуживать Highload etc. При чем на ровном месте. Оно надо?
все процессы доставки секретов асинхронные. То есть это означает определенный порядок при релизе (сначала добавляем секрет, потом проверяем, что он доехал, потом уже обновляем приложение), что уже гемор. Как же просто было с sops! Тупо закидал манифестов и подождал. А еще означает, что нужно все покрывать мониторингом. А это уже веселее - потому что весь опенсурс, откровенно скажу, сделан из пофигизма, говна и палок. Даже в таких известных и давно используемых компонентах вроде cert-manager есть куча проблем, которые че-то авторы не торопятся исправлять. И шанс налететь на корнес кейсы тем увеличивается, чем больше разнородных компонентов в инфре. Вот - уже из статьи ясно - одним вольтом мы не обойдемся, нам еще ESO надо зашлифовать, потом kyverno какую-нибудь еще и так далее по перечню. Получается, как лего. Только в отличии от лего - тут кубики разномастные и не очень подходят друг к другу ))) Как там договорится - доработать напильником
. И тут сделан акцент на "гарантировать безопасность при доставке секретов" - доставка секретов безопасная, а вот ее итоговое хранение в Opaque Secrets почти в открытом виде (так как все мы знаем, на сколько безопасен base64 энкодинг =) ) - действительно нет.
с этим нет проблемы. Потому что в etcd секреты пошифрованы. А если вы не верите в RBAC кубера, то у меня для вас очень плохие новости, потому что любые меры поиграть в прятки с секретами обеспечены на провал. Тупо имеем кластер админа - значит, либо мы уже легко можем переконфигурировать средства доставки секретов, либо запустить паразитные нагрузки, которые прикидываются легитимными...
В следующем посте я расскажу об использовании данного решения, о его плюсах и минусах, а также о задачах, которые остались открытыми. На этом у меня все, готов ответить на ваши вопросы.
очень ждем, потому что из всего вышеописанного - я попробовал все. И везде какие-то корнер кейсы и неприятные эксплуатационные особенности. Касательно переменных окружения - на мой вкус, это еще менее безопасно, чем (временный) файл. `cat /proc/<pid>/environ` и ХАТОВА. А vault-env - мы ловили приключения с недоступностью вольта, тогда приложение просто играет в поваляшки. Даже не знаю что лучше - иметь не очень актуальную версию секрета, но хоть как-то работать. Либо сразу падать. Тема мониторинга тоже не раскрыта. Тот же инжектор - ну, звучит круто, пока ты действительно не считаешь расходы на сайдкары и не думаешь, что произойдет, когда он завалится по любой причине. А это обязательно случится. Лишиться радости запуска подов в кластере? В статье подсвечен очень верный тезис - надо делать так, чтобы доступность системы не страдала. Не безопасность любой ценой, а взвешенный разумный компромисс. Но пока у меня складывается ощущение, что эти ИБ штуки скорее мешают, чем помогают и тем более создают скорее иллюзию ложной безопасности. Ну, что толку от того, что секреты спрятаны, если можно утащить сервисный токен с доступом к апи кластера, а дальше все понятно? Ну, и, конечно, вольт может прямо сиять и сверкать - в случае, например, паролек одноразок (динамические секреты), но будем честны - сколько пользователей вольта реально их использует, а не надувает щеки? Какой-то прям resume driven adoption технологий вовсю, а не практическая необходимость.
Для монтирования секретов в файловую систему pod используется Pod Security Policies. Он был объявлен как deprecated в Kubernetes v1.21, и окончательно удален в 1.25.
это требует расшифровки, потому что я честно не очень понимаю, как связаны монтирование секретов и PSP.
Let's Encrypt сломал эту модель, доказав, что SSL‑сертификаты могут быть бесплатными, автоматизированными и более безопасными, чем дорогие альтернативы.
да, в частности, в момент, когда ты понимаешь, что у тебя сертификат не продлился потому что
cert-manager сломался
а cloudflare (dns challenge через который ты сделал) обновил API
it's genial. Закрывается мониторингом. Но будем честны - на горизонте 3 месяца до выпуска нового сертификата - кто будет этим морочиться?
Можно выпустить неограниченное количество сертификатов и все они будут выглядеть как одинаковый зелёный замочек в адресной строке.
и это проблема. Смотри мое сообщение. Отличить фейк сайт однодневку со скамом от настоящего сайта становится по замочку невозможно. А че такого - зато все соединение шифровано и скрыто от товарища майора и провайдера (это, кстати, добро, потому что всякие Мегафоны оборзели инжектить рекламные джаваскрипты в плоский хттп трафик)
Почему? Потому что LE это способ Гугла убить все и подмять под себя. Сам по себе "прекрасный" LE использует уродами вроде всяких скамеров для создания бесплатных сайтов с фишингом, казино и прочими прелестями жизни, так как проверка идет только по http. Был бы фильтр в виде "покажи документы" - уже было бы попроще жить. А, кстати, мы только что описали вот те самые дорогие OV сертификаты. С ручной верификацией, угу. А ничего - что поддержка структуры УЦ и правильного списка отзыва сертификатов денег стоит? Бесплатный сыр только в мышеловке бывает, правда? Другой вопрос, что даже платные и коммерческие УЦ не всегда играют по правилам. Был же уже скандал и не один - вроде такого https://www.opennet.ru/opennews/art.shtml?num=48166
Но значит ли это, что секретики нужно доверять открытым проектам вроде Let's Encrypt? Ну, вряд ли.
С точки зрения эксплуатационщика у меня есть претензии и к платным вручную распределяемым сертификатам и к LE.
LE: низкие рейт лимиты, так что если ты был недостаточно умен, что бы делать DNS проверку (а не HTTP) и выписывать вайлдкард на все сервисы, то в случае переезда с хостинга на хостинг, ты можешь просто встрять. Сертификат не выписать (!) А если спросите где старый - ну, предположите, что прошлый хостинг вас кинул и выкинул на мороз. С концами. Такие дела. Что делать? Ну, приплыли.
Платные сертификаты: ручной процесс выпуска и деплоя со всеми вытекающими последствиями. Очень высокий риск человеческого фактора (забыли обновить). Зато надежно ))))
Такая хорошая статья. И в конце реклама ОТУСа. Емае. Касательно перспектив - все слишком пессимистично. Учитывая, что мы сами не знаем, как думаем. Я согласен с комментарием выше https://habr.com/ru/companies/otus/articles/943840/#comment_28827744 - вполне возможно, что человек сам статистическая машина, и на самом деле сам не мыслит... а просто ловит сигналы из Вселенной
Не уверен что есть какой-то смысл запрещать разработчикам доступ к конвейерам, когда эти самые конвейеры
вообще-то вполне есть. Недоверенный код и все такое. Все то, что разрабы коммитят в репо - должно проходить процесс ревью тимлидом. Иначе никак. И тут как раз вот эти все эфемерные и фичеветковые пайплайны и стенды становятся риском. За ними никто не следит, потому что думает, что там ничего ценного нет.
когда я увидел repobootstrap.py как ссылку, я грешным делом решил, что код опубликован. Как я понимаю - в обозримом будущем опенсурс ждать не придется ? То есть статья про концепт в целом ? Одобряем. Все рано или приходят к задаче шаблонищации пайплайнов, в частности, когда количество команд и репозиториев превышает определенный предел. Другой вопрос - почему не сделать все на чем то более адекватном, вроде woodpecker или попросту не оформить CI/cd как отдельный продукт, скажем, на голанге.
По пайплайнам всегда еще возникает проблема с тем, что если разработчики имеют доступ к их редактированию - это попросту не безопасно. Потенциальная возможность запуска недоверенного кода. Как решаете ?
Статью только переименовать. Какие карточки ? Языковые типа anki ? Лично мне слово карточка в первую очередь вызывает ассоциацию с банковскими продуктами - дебетовыми или кредитными картами. Ну, край, могли быть карточки лояльности.
Проблема в том, что все эти средства родительского контроля рудиментарны и по сути ни от чего не ограждают. Это просто кидок кости от крупных корпораций, чтобы сказать, что проблема не на их стороне.
Вы меня извините, но порядочному толковому сотруднику точно нужен рут, все данные, расклад, архитектура, без этого админ не сможет грамотно научится управлять инфрой/процессами
Как раз наоборот. Грамотного и толковому сотруднику - нужны минимальные привилегии, а не рут.
Короче, все это чушь, лучше занимайтесь своими сотрудниками, не проверять часы в жире, а разговаривать и понимать мотивацию людей нужно, насколько толковые, какие амбиции и какой опыт, это даёт гораздо больше чем вот эта вот снимая безопасность
Я тоже считаю, что надо нанимать порядочных и толковых людей, а не идиотов. Только вот это все равно не страхует от того, что компьютер «порядочного и толкового» сотрудника не будет заражен вирусом. Знаете, угроз каждый день меняются. И, к сожалению, злоумышленники становятся все хитрее и хитрее.
А теперь про permitrootlogin yes, что если вам нужен доступ к либвирту по сокету, а у пользака таких прав нет, будете колхоз городить и палки в работу вставлять?
Надо разбираться, зачем он нужен, а не давать возможность направо и налево пользоваться. Может быть вы дверь от своей квартиры не запираете? Или ключ оставляете в доступности всем? Что-то сомневаюсь, будьте последовательны.
Можно ли защитить ci, конечно, ваулт апрол и т.д., только назовите компанию где настолько не доверяют своим сотрудникам (которым выдают доступ в проекты инфры ci), чтобы городить на каждый чих такие строгие меры?
ну, или - в контейнере /etc/hosts условный. Какой-нибудь секурити тул будет верещать - Алярм, опасность, а ничего такого нет. Хотя, по-чесноку, наверняка, и с systemd-nspawm и chroot окружениями будет такая же ботва.
Это вопрос восприятия. Не нужно воспринимать контейнеры аналогом виртуалок или железных серверов - они этим не являются.
я никогда их аналогом виртуалок и не называл
Контейнер - это обычный процесс/приложение, просто дополнительно ограниченное ядром в плане того, что это приложение видит
да
Грубо говоря, контейнер намного ближе к запуску бинарника в chroot чем к виртуалке.
да
Поэтому в плане управления и мониторинга от контейнеров нужно ждать примерно того же, что и от любых процессов - т.е. только тех возможностей, которые реализованы в самом приложении
нет. Именно за счет того, что с точки зрения докера и CRI контейнеры "существуют", а с точки зрения ядра линукс - нет - у нас возникают проблемы, связанные с тем, чтобы правильно рапортовать, например, что процесс ХХХ случился именно в контейнере YYY. Это примерно такая же проблема совместимости, как между nftables и iptables. Повторюсь - тулинг недостаточно зрелый. Хотя и двигается в этом направлении.
контролей и обзервабилити у контейнеров меньше - это можете даже не оспаривать. Тулинг пока не созрел до конца, увы. Условный Falco берешь - а он путь к файлу пишет не так, как надо. Сидишь и гадаешь (я утрирую) - проблема на хост машине или в контейнере. Так что проблема более широкая.
тут сознательно упускается момент, что
абсолютно безопасную систему не построить
следствие - надо идти на компромиссы
аудит вольта - уже явно лучше аудита секретов в кубере
и если секрет утечет - его можно будет, условно, поменять "одной кнопкой" везде, а не бегать по 100500 секретов в 100500 кластеров, лихорадочно пытаясь понять - а что надо менять-то!
ну, и я ниже писал - надо от статических секретов уходить. Те же сертификаты с коротким сроком жизни (а vault умеет быть pki) или секреты одноразки - уже сильно сокращают поверхность атаки для злоумышленника. И тут сильно могут помочь средства раннего обнаружения атак. Очевидно, что если кто-то лазит по ФС контейнера с запросами вида `cat /proc/<pid>/environ` - это уже аномалия и нас уже ломают. А если секрет лежит в файле - ну, пойди отличи - легитимная ли это деятельность или нет.
а это проблема, потому что автоматически влетаем в следующие вопросы
как мы будем вольт бекапить? Если нет другого золотого источника правды - ну, вольт им становится, значит нам нужно подходить к нему как к питомцу. Лелеять, лечить.
Vault автоматом становится критическим узлом на пути всего - деплоя, запуска и прочего. Вольт играет в поваляшки - инфраструктура начинает напоминать дорогущий чемодан без ручки. Следовательно, автоматом требования к HA, возможности обслуживать Highload etc. При чем на ровном месте. Оно надо?
все процессы доставки секретов асинхронные. То есть это означает определенный порядок при релизе (сначала добавляем секрет, потом проверяем, что он доехал, потом уже обновляем приложение), что уже гемор. Как же просто было с sops! Тупо закидал манифестов и подождал. А еще означает, что нужно все покрывать мониторингом. А это уже веселее - потому что весь опенсурс, откровенно скажу, сделан из пофигизма, говна и палок. Даже в таких известных и давно используемых компонентах вроде cert-manager есть куча проблем, которые че-то авторы не торопятся исправлять. И шанс налететь на корнес кейсы тем увеличивается, чем больше разнородных компонентов в инфре. Вот - уже из статьи ясно - одним вольтом мы не обойдемся, нам еще ESO надо зашлифовать, потом kyverno какую-нибудь еще и так далее по перечню. Получается, как лего. Только в отличии от лего - тут кубики разномастные и не очень подходят друг к другу ))) Как там договорится - доработать напильником
с этим нет проблемы. Потому что в etcd секреты пошифрованы. А если вы не верите в RBAC кубера, то у меня для вас очень плохие новости, потому что любые меры поиграть в прятки с секретами обеспечены на провал. Тупо имеем кластер админа - значит, либо мы уже легко можем переконфигурировать средства доставки секретов, либо запустить паразитные нагрузки, которые прикидываются легитимными...
очень ждем, потому что из всего вышеописанного - я попробовал все. И везде какие-то корнер кейсы и неприятные эксплуатационные особенности. Касательно переменных окружения - на мой вкус, это еще менее безопасно, чем (временный) файл. `cat /proc/<pid>/environ` и ХАТОВА. А vault-env - мы ловили приключения с недоступностью вольта, тогда приложение просто играет в поваляшки. Даже не знаю что лучше - иметь не очень актуальную версию секрета, но хоть как-то работать. Либо сразу падать. Тема мониторинга тоже не раскрыта. Тот же инжектор - ну, звучит круто, пока ты действительно не считаешь расходы на сайдкары и не думаешь, что произойдет, когда он завалится по любой причине. А это обязательно случится. Лишиться радости запуска подов в кластере? В статье подсвечен очень верный тезис - надо делать так, чтобы доступность системы не страдала. Не безопасность любой ценой, а взвешенный разумный компромисс. Но пока у меня складывается ощущение, что эти ИБ штуки скорее мешают, чем помогают и тем более создают скорее иллюзию ложной безопасности. Ну, что толку от того, что секреты спрятаны, если можно утащить сервисный токен с доступом к апи кластера, а дальше все понятно? Ну, и, конечно, вольт может прямо сиять и сверкать - в случае, например, паролек одноразок (динамические секреты), но будем честны - сколько пользователей вольта реально их использует, а не надувает щеки? Какой-то прям resume driven adoption технологий вовсю, а не практическая необходимость.
это требует расшифровки, потому что я честно не очень понимаю, как связаны монтирование секретов и PSP.
да, в частности, в момент, когда ты понимаешь, что у тебя сертификат не продлился потому что
cert-manager сломался
а cloudflare (dns challenge через который ты сделал) обновил API
it's genial. Закрывается мониторингом. Но будем честны - на горизонте 3 месяца до выпуска нового сертификата - кто будет этим морочиться?
и это проблема. Смотри мое сообщение. Отличить фейк сайт однодневку со скамом от настоящего сайта становится по замочку невозможно. А че такого - зато все соединение шифровано и скрыто от товарища майора и провайдера (это, кстати, добро, потому что всякие Мегафоны оборзели инжектить рекламные джаваскрипты в плоский хттп трафик)
Автор оригинального текста, ты идиот.
Почему? Потому что LE это способ Гугла убить все и подмять под себя. Сам по себе "прекрасный" LE использует уродами вроде всяких скамеров для создания бесплатных сайтов с фишингом, казино и прочими прелестями жизни, так как проверка идет только по http. Был бы фильтр в виде "покажи документы" - уже было бы попроще жить. А, кстати, мы только что описали вот те самые дорогие OV сертификаты. С ручной верификацией, угу. А ничего - что поддержка структуры УЦ и правильного списка отзыва сертификатов денег стоит? Бесплатный сыр только в мышеловке бывает, правда? Другой вопрос, что даже платные и коммерческие УЦ не всегда играют по правилам. Был же уже скандал и не один - вроде такого https://www.opennet.ru/opennews/art.shtml?num=48166
Но значит ли это, что секретики нужно доверять открытым проектам вроде Let's Encrypt? Ну, вряд ли.
С точки зрения эксплуатационщика у меня есть претензии и к платным вручную распределяемым сертификатам и к LE.
LE: низкие рейт лимиты, так что если ты был недостаточно умен, что бы делать DNS проверку (а не HTTP) и выписывать вайлдкард на все сервисы, то в случае переезда с хостинга на хостинг, ты можешь просто встрять. Сертификат не выписать (!) А если спросите где старый - ну, предположите, что прошлый хостинг вас кинул и выкинул на мороз. С концами. Такие дела. Что делать? Ну, приплыли.
Платные сертификаты: ручной процесс выпуска и деплоя со всеми вытекающими последствиями. Очень высокий риск человеческого фактора (забыли обновить). Зато надежно ))))
Такая хорошая статья. И в конце реклама ОТУСа. Емае.
Касательно перспектив - все слишком пессимистично. Учитывая, что мы сами не знаем, как думаем. Я согласен с комментарием выше https://habr.com/ru/companies/otus/articles/943840/#comment_28827744 - вполне возможно, что человек сам статистическая машина, и на самом деле сам не мыслит... а просто ловит сигналы из Вселенной
вообще-то вполне есть. Недоверенный код и все такое. Все то, что разрабы коммитят в репо - должно проходить процесс ревью тимлидом. Иначе никак. И тут как раз вот эти все эфемерные и фичеветковые пайплайны и стенды становятся риском. За ними никто не следит, потому что думает, что там ничего ценного нет.
Привет!
когда я увидел repobootstrap.py как ссылку, я грешным делом решил, что код опубликован. Как я понимаю - в обозримом будущем опенсурс ждать не придется ? То есть статья про концепт в целом ? Одобряем. Все рано или приходят к задаче шаблонищации пайплайнов, в частности, когда количество команд и репозиториев превышает определенный предел. Другой вопрос - почему не сделать все на чем то более адекватном, вроде woodpecker или попросту не оформить CI/cd как отдельный продукт, скажем, на голанге.
По пайплайнам всегда еще возникает проблема с тем, что если разработчики имеют доступ к их редактированию - это попросту не безопасно. Потенциальная возможность запуска недоверенного кода. Как решаете ?
только не эластик. даже quickwit будет лучше или что-то более специализированное. КХ тоже норм работает
я высказал ровно то же мнение
Статью только переименовать. Какие карточки ? Языковые типа anki ? Лично мне слово карточка в первую очередь вызывает ассоциацию с банковскими продуктами - дебетовыми или кредитными картами. Ну, край, могли быть карточки лояльности.
У каждого своя профдеформация
Спасибо за статью. Теперь не так страшно делать умный дом. Но вопрос такой. Сколько это обошлось ? Можно примерную смету посмотреть ?
Проблема в том, что все эти средства родительского контроля рудиментарны и по сути ни от чего не ограждают. Это просто кидок кости от крупных корпораций, чтобы сказать, что проблема не на их стороне.
Как раз наоборот. Грамотного и толковому сотруднику - нужны минимальные привилегии, а не рут.
Я тоже считаю, что надо нанимать порядочных и толковых людей, а не идиотов. Только вот это все равно не страхует от того, что компьютер «порядочного и толкового» сотрудника не будет заражен вирусом. Знаете, угроз каждый день меняются. И, к сожалению, злоумышленники становятся все хитрее и хитрее.
Надо разбираться, зачем он нужен, а не давать возможность направо и налево пользоваться. Может быть вы дверь от своей квартиры не запираете? Или ключ оставляете в доступности всем? Что-то сомневаюсь, будьте последовательны.
Посмотрите доклады уважаемого @0xffd
ну, или - в контейнере /etc/hosts условный. Какой-нибудь секурити тул будет верещать - Алярм, опасность, а ничего такого нет. Хотя, по-чесноку, наверняка, и с systemd-nspawm и chroot окружениями будет такая же ботва.
я никогда их аналогом виртуалок и не называл
да
да
нет. Именно за счет того, что с точки зрения докера и CRI контейнеры "существуют", а с точки зрения ядра линукс - нет - у нас возникают проблемы, связанные с тем, чтобы правильно рапортовать, например, что процесс ХХХ случился именно в контейнере YYY. Это примерно такая же проблема совместимости, как между nftables и iptables. Повторюсь - тулинг недостаточно зрелый. Хотя и двигается в этом направлении.
конфиги надо не бекапить, а
либо бекапим виртуалку целиком средствами облака
а еще лучше - раскладываем конфиги любимым средством puppet/salt/ansible и вместо бекапа просто имеем единую точку правды.
контролей и обзервабилити у контейнеров меньше - это можете даже не оспаривать. Тулинг пока не созрел до конца, увы. Условный Falco берешь - а он путь к файлу пишет не так, как надо. Сидишь и гадаешь (я утрирую) - проблема на хост машине или в контейнере. Так что проблема более широкая.