Комментарии 49
А я посмотрел-посмотрел на эту monstrosity и начал использовать sops. Который, кстати, секреты хранит как раз в гите. Зашированными gpg-ключами (и другими kms).
Sops - годная штука для небольших инсталляций. Когда вокруг кровавый энтерпрайз, тысячи виртуалок и кубернетесы - vault единственный вариант
Не совсем согласен. Раньше этот кровавый энтерпрайз прекрасно жил годами с паролями в куче мест исходного кода, в переменных окружения тех самых тысяч серверов, в текстовых файлах на нмх же - и было норм. И вдруг такой вот двухкластерный монстр, от архитектуры которого уши заворачиваются. Что-то тут не так...
А на заре мой молодости было достаточно межсетевого жэкрана на внешнем периметре (Интернет). Все внтури было едва ли не плоской сетью, и никто особо не парился. А теперь какой-то Zero Trust подавай...
С жиру бесятся? Или все-таки мир меняется?
Речь не про молодость и сейчас, а про то, какие изменения были сделаны в одночасье, скорее всего просто по требованию безопасников.
кровавый энтерпрайз прекрасно жил годами с паролями в куче мест исходного кода, в переменных окружения тех самых тысяч серверов, в текстовых файлах на нмх же - и было норм.
Т.е. вы действительно считаете, что это и сейчас норм, и ИТ стало переходить на централизованное хранение секретов супротив души, просто из-за дурацких требований безопасников?
Каждый инструмент под свою задачу. Мы решали наши проблемы под которые волт больше подходит. Итоговая инфраструктура появилась не сразу. Первоначально она выглядела так:
* Балансер для возможности проводить работы на одной и более нод волта
* Волт в кол-ве 3 инстанса для отказоустойчивости и доступности 24х7
* Консул как хранилище для хранения БД волта. Но он уже был запущен на всю компанию, т.к. использовался в Service Discovery.
И по чуть-чуть для улучшения доступности сервиса, для закрытия выясненных проблем инфраструктура менялась, порой усложнялась, порой упрощалась. На сколько знаю, сейчас переводят волт на Raft хранилище, что даёт свои плюсы и минусы.
Я вот хочу "расшарить" хранилище паролей для жены.
Но сейчас хранилище существует в виде Keepass-файла, в котором нет разграничения уровней доступа да и вообще нужно использовать приложение и иметь доступ к файлу.
При выборе системы для реализации этой задачи для меня в первую очередь необходимо разграничения уровней доступа - чтобы я мог видеть всё, а она только то что нужно ей, плюс чтобы это было бесплатно и/или можно было поднять на своём сервере.
Веб-интерфейс опционален, но может быть полезным для повышения доступности.
До этой статьи я рассматривал только Bitwarden, теперь вот получается что и HashiCorp Vault OSS тоже может подойти.
А вот sops для моего кейса не подходит :(
Может есть ещё варианты?
sops (за вычетом отсутствия UI) для этой задачи как раз подходит невероятно хорошо.
Сделайте каталог с sops-секретами, в котором у каждого файла свой список ключей. Вам жена даже сможет писать секреты, которые потом сама прочитать не сможет.
Вообще, притаскивание жены в это обсуждение делает всё комичным и неудбным, потому что кто в семейных отношениях всё хранит в git'е? В каком гите? В семейном? В корпоративном?
А вот для команд - это офигенно удобно.
(Вообще, ваш случай хорошо решается 1password'ом).
Откуда вообще взялось требование хранить секреты в гите?
У топикастера - ни от куда. Во всех остальных случаях, хранение секретов в гите даёт восхитительное свойство - секрет меняется одновременно с кодом.
У любого внешнего волта есть простая глупая проблема. Допустим, у нас есть foo_secret. И вот у меня в старом коде это был hex вида 0xDEADBEAFMYPRIVATEVALLET00, а в новом коде его поменяли на 0xdeadbeafmyprivatevallet00. Не важно почему, важно, что поменяли. Допустим, раньше libfoo умела с капсом, а в новом релизе больше не умеет.
И вот в какой момент я должен пойти и поменять значение на внешнем сервере? До релиза? (сломав ребилд продакшена). После релиза? (Сделав невозможным релиз т.к. старый код не хочет маленькие буквы). Прям ровно в тот момент, когда старые сервисы легли, а новые поднялись? (реализм, да, bluegreen, да?).
А когда секреты в гите, эта проблема решается изящно и атомарно.
Может показаться, что это выдуманный пример (и он таковой), но я в своей карьере столько с секретами намучался, что могу довольно уверенно сказать, что рассинхронизация конфигурации (а конфиг в одном месте, секрет в другом месте - это и есть рассинхронизация) - это Большое Зло с отложенными и иногда проявляющимися последствиями. А Большое оно потому, что любой баг в районе конфигурации с секретами кратно сложнее отлаживать (чем, например, обычный баг с ошибкой в IP адресе), потому что все старательно содержимое секрета прячут и что именно сломалось не пишут.
До релиза идём и создаём новый секрет для новой версии. В новой версии коммитим новый путь до секрета в хранилище. Никакой проблемы, вроде.
Хранение секретов в гите даёт восхитительное свойство - секрет меняется одновременно с кодом
А разве хранить секреты рядом с кодом это хорошо?
Есть код приложения и его нужно будет развернуть на кучу стендов (дев, тест, ИФТ, нагрузка, прод в конце концов) - и что везде секрет будет одинаковым и будет находится в ребе доступной разработчикам? Продовый секрет?
Секреты должны быть отделены от кода приложения как раз по этим причинам:
значения секретов могут отличаться от стенда к стенду и их изменения не должны приводить к изменению в "коде" приложения
значения некоторых секретов не должны быть доступны всем
Да, можно в репе хранить секреты сразу для всех стендов, а более секретные секреты шифровать более секретным ключом, но профит-то в чём?
При добавлении стенда - нужно будет вносить правки в репу приложения.
При смене значения - тоже
Приложение ещё и должно будет знать с каким кнкретно секретом ему нужно работать сейчас
Допустим, у нас есть foo_secret. И вот у меня в старом коде это был hex вида 0xDEADBEAFMYPRIVATEVALLET00, а в новом коде его поменяли на 0xdeadbeafmyprivatevallet00.
И вот в какой момент я должен пойти и поменять значение на внешнем сервере?
Заводим новый секрет foo_secret_2 и размещаём в нём новое значение:
старая версия будет использовать старый секрет и всё ок
новая будет использовать новый и всё ок
когда старая точно не будет использоваться - удалим старый секрет
По модели sops'а - хорошо, и я написал почему. Разные среды имеют свои секреты, которые банально лежат по разным путям (/production, /staging, /whatever).
... И тут ещё надо понимать про какой репозиторий мы говорим. Не про репозиторий приложения, а про репозиторий инфраструктуры. IaaC же? Есть (chart/playbook/whatever), где-то есть инвентори и т.д., там же лежат и шифрованные секреты.
При появлении стейджинга вам всё равно его параметры куда-то надо записать. Вот это "куда-то" - гит. Если у вас стейджинги "записаны" во внешнюю базу и формируются динамически, то, обычно, у вас где-то есть ссылка на фильтр выборки этого стейджинга. Вот там же и секреты лежат. Если же у вас нет гита, из которого вытекает информация о том, куда деплоить, то это уже не IaaC, а "оснастка управления контроллером домена" в стиле винды, и строгий анти-паттерн для ci/cd.
С foo_secret_2 вы только что придумали наколенное версионирование секретов в стиле "zip-файла с кодом приложения в аттаче в письме". Рудиментарное и неудобное.
И тут ещё надо понимать про какой репозиторий мы говорим. Не про репозиторий приложения, а про репозиторий инфраструктуры.
А когда секреты в гите, эта проблема решается изящно и атомарно.
Если репы разные, то о какой атомарности будет идти речь?
А если нет атомарности то позволю себе задать вам ваш же вопрос: И вот в какой момент я должен пойти и поменять значение на внешнем сервере в репе с секретами?
И если обсуждается вариант в котором хранилище секретов отделено от хранилища кода, то в чём профит использования именно git для отдельного хранилища секретов? Чем условная БД хуже?
С
foo_secret_2вы только что придумали наколенное версионирование секретов
Ага, и не вижу тут ничего плохого - при работе с самим приложением тоже используется версионирование и чего плохого в этом нет.
Условно "для работы прилодения версии 2.x.x используются секреты foo_x_2".
Секреты лежат в той же репе, в которой лежит код деплоя. У вас всегда в финале одна репа, потому что если у вас несколько реп, то у вас нет source of truth про инфраструктуру и нет адекватного iaac'а.
У вас может быть несколько реп для разных компонент, но в этом случае каждая репа отвечает за свой кусок, и секреты своего куска и хранит.
... С вашим версионированием секретов всё чудесно, потому что если у вас, например, меняется не приложение а код деплоя, то секреты тоже могут меняться (рефакторинг - раньше хранили целиком url, а теперь только project_id), и у вас получается матрица "версия кода деплоя/версия приложения", и линейная система версионирования секретов рассыпается. А двухмерную делать - это отдельный восхитительный процесс, в котором кто-то должен пойти и сделать новые секреты новой версии под каждый новый бамп версии секретов.
А если у вас версия per secret, то тогда возникает проблема с тем, кому в каком порядке бампать и какую версию выбрать для нового секрета в момент, например, даунгрейда.
Самописная система управления версиями на соглашениях "в голове" - это прямой путь в devops-ад.
Секреты лежат в той же репе, в которой лежит код деплоя.
Если "код деплоя" это не "код приложения", который эти секреты потребляет то заверяемая атомарность изменений становится недоступна:
Допустим, у нас есть
foo_secret.
И в какой-то момент в коде изменили его формат и возникает вопрос в какой момент менять значение в внешнем (по отношению к коду) хранилищу.
А когда секреты в гите, эта проблема решается изящно и атомарно так как хранение секретов в гите даёт восхитительное свойство - секрет меняется одновременно с кодом.
А если "код деплоя" это "код приложения", то внезапно оказывается что в этой репе должны лежать секреты для всех окружений что для меня не выглядит хорошим решением так как тут
есть утечка как имени и количества имён этих самых окружений
есть доступ (пусть и к зашифрованным) данным этих самых окружений, и если утекёт (например по другому каналу) ключ, позволяющих их расшифровать, то и сами значения утекут и этот момент нельзя никак проконтролировать.
При хранении секретов в отдельном хранилище доступ к этому хранилищу будет сильно уже (например там не будет разработчиков джунов или даже стажёров), плюс специализированные решения (тот же Vault) имеют логи обращений, дающие возможность анализа источника утечки.
Самописная система управления версиями на соглашениях "в голове" - это прямой путь в devops-ад.
Я и не говорю что моя схема идеальна - она вообще появилась за несколько минут чисто для решения озвученной проблемы "смены формата секрета для разных версий приложения при условии раздельного хранения секретов и кода приложения".
И эта проблема не решается git-ом просто потому что это git, если только секреты не хранятся в одной репе с кодом, чего в моей практике не встречалось.
Да и вы ведете речь про "репозиторий с кодом деплоя" и "источник истины инфраструктуры" что, на мой взгляд, предполагает его хранение отдельно от "кода ПО", репозиториев с которыми, с учётом тренда на микросервисность, может быть очень много (по репе на микросервис! и чтобы языки были разными).
Можно реализовать связку "версия секрета" с "версией ПО" через метки версий там и там, но это, по большому счёту, не требует хранения секретов именно в git это требует поддержки "леблов" со стороны места хранения секретов.
Если "код деплоя" это не "код приложения", который эти секреты
потребляет то заверяемая атомарность изменений становится недоступна
Код деплоя деплоит не 'latest'. Надеюсь, вы так не делаете. Код деплоя деплоит конкретную версию, с которой ассоциирован конкретный секрет. В этом и прелесть подхода. У вас есть финальный код, который знает:
куда
какую версию
с каким секретом
деплоить. И это происходит тогда, когда этот код запущен.
Заметим, появление на свет версии (компиляция/сборка/теги) совершенно не связные процессы. Для секретов важен именно код деплоя; именно там и должны храниться секреты.
Если что, sops как раз и построен на модели "хранить секреты в git'е". Инфраструктурные гиты обычно не в публичном доступе (в отличие от кода, который часто может быть публичным), и да, риск disclose есть. Частично это может быть скомпенсировано использованием kms (вместо gpg-ключей).
Собственно, вот их threat model https://github.com/mozilla/sops#threat-model
Вообще, притаскивание жены в это обсуждение делает всё комичным и неудбным, потому что кто в семейных отношениях всё хранит в git'е? В каком гите? В семейном? В корпоративном?
Так про git и не было требования.
Я увидел что обсуждаемый в статье Vault подходит под мои нужды.
В комментарии что он монструозный и есть альтернативный вариант, вот этому комменту я и ответил что альтернатива это хорошо, но не все кейсы она подкоывает и показал свой кейс.
При том что вариант из комментария не полностью и кейсы из статьи покрывает.
Все конечно классно и IT отдел Тинь-Банка конечно молодец, но как автор статьи прокомментирует "недоразумения" с переводами за границу. Почему в принципе возможен перевод с комиссией равной всей сумме перевода? Почему пользователи не были должным образом предупреждены? Я бы обвинил банк в мошенничестве и воровстве, но прежде считаю должным выслушать какие-то объяснения. Если они покажутся читателям Хабра недостаточными, думаю его аудитория имеет моральное право изгнать отсюда этот блог как минимум "до лучших времен".
Поставил минусы именно по этим причинам.
Минусы за качественную техническую статью??
Я могу понять недовольство банком (у самого исходящий SWIFT давно висит). Даже задать вопрос "какого фига творится" еще куда ни шло. Хотя и очевидно, что он не по адресу (причем не только не к автору, но даже и не к банку).
Но изгнать полезный блог напрочь... Да чего уж там, вообще тогда блоги всех банков, ибо всех лихорадит... Ну ведь перебор же. Не пофиг ли, в чьем блоге статья, если полезная и интересная.
Я понимаю нервозность вокруг. Многие даже на ключи от машины ругаются, когда торопятся, а "они потерялись". Но давайте все-таки постраемся продышаться. немного успокоиться и сохранить технические материалы. Они нам еще пригодятся.
Этот пост - реклама в сми и пока представители банка не дали в этом сми ответ - банк не без основания можно считать мошеннической структурой. Хорошая статья, с помощью которой мошенники привлекают к своей структуре будущих жертв, должна быть удалена вместе с блогом, но если ее автор пожелает, мы с удовольствием прочитаем ее от его частного и честного имени.
Мы обсуждаем действия компании в блоге этой компании, даже в такой формулировке я не вижу нарушения правил хабра.
Ответа на довольно серьезные обвинения представители банка не могут дать вот уже несколько часов, хотя главный капитал банка - это доверие к нему его клиентов. Каким должно быть у человека помутнение разума, чтобы он продолжал быть или решил стать после этого клиентом Тинькофф банка?
Мы обсуждаем действия компании в блоге этой компании, даже в такой формулировке я не вижу нарушения правил хабра.
Я ни в коем случае не говорю о нарушении вами правил хабра. Более того, я как раз упомянул `Даже задать вопрос "какого фига творится" еще куда ни шло `. Я счел минусы статье перебором.
Ероме того, вот я присматриваю новый банк. Да неужто для выбора я буду корпоративные блоги банков на Хабре читать?
"Вау, как здорово они хранят секреты для приложений! А открою-ка у них счет!" - в голове не укладывается. Возможно индивидуальные особенности и привычки. Я и рекламу-то фильтрую и не отвлекаюсь на нее, никакой adblock не нужен. И серьезный выбор (банка, автомобиля...) я обычно делаю с чеклистом и табличкой в Excel. Конечно, общее впечатление имеет некоторый вес, но существенно менее значительный, чем реальные факторы. Впрочем, проехали, это к делу не относится.
Точно реклама, то-то мне после статьи захотелось не vaul поковырять, а кредитку оформить
если ее автор пожелает, мы с удовольствием прочитаем ее от его частного и честного имени.
Не только перевод, но и возврат перевода, который не прошёл. Две комиссии за одну услугу, которая не была оказана - новое слово в клиентоориентированности!
Потерпите месяц-другой, Свифт отберут у всех и ваша боль исчезнет сама собой
Я бы не переживал так сильно: "Водичка дырочку найдет"(Зевс).
#/media/%D0%A4%D0%B0%D0%B9%D0%BB:Orazio_Gentileschi_-_Dana%C3%AB_and_the_Shower_of_Gold_-_2016.6_-_J._Paul_Getty_Museum.jpg){kind=link}
Доброго дня,
Никак не прокомментирую. Эта статья расшифровка моего выступления в 2019-м году https://www.youtube.com/watch?v=pP8909tFllM с поправкой на изменения за последние 3 года.
Я, также, не могу выложить статью в свой личный блог, т.к. и доклад и статья это труд многих людей работающих, или работавших, в Тинькофф:
* Команды которые создавали потребности в инструменте и автоматизации вокруг него
* Коллеги, которые ревьюили и помогали менять текст выступления
* Коллеги, которые ревьюили и правили текст этой статьи
Готов ответить на вопросы по волту, хранению секретов, по автоматизации вокруг инсталляции.
Я не знаю, как кто и как где, но с моей и еще с точки зрения огромного числа людей и правовых норм свободных государств взимание с человека платы коммерческой структурой без предоставления взамен какой-либо ценности - есть либо мошенничество, либо воровство. Тут идет речь конечно о моральной оценке: в стране без закона, законной оценки вам никто не даст, кроме жандармов и полицаев. Когда вы выпускаете статью, рекламирующую бренд и направленную на увеличение доверия к такой коммерческой структуре, вы, Юрий Шуткин, разделяете ответственность за ее преступления, не как соучастник, но все же в какой-то мере.
В посте намеренно нет тезисов "какие мы молодцы", потому что это никому не интересно. Пост про опыт построения сервиса для хранения и использования секретов. О том с какими сложностями столкнулись и как исправляли.
История с 7 избыточными ключами из которых необходимо всего лишь 3, да и то не сразу смогли собрать:
Показывает что без постоянных проверок и готовности ввести свою часть ключа мы не получили высокую доступность, т.к. ключи могут быть потеряны, забыты, или ещё какой фактор может сработать.
История про бэкапы:
Не было видно по графиками что что-то совсем пошло не так. Час от часу бэкап рос на 4Мб, ну мало ли, команды сохраняют секреты, пользуются сервисом, хорошо ведь. И только когда случился сбой: сервис стал очень сильно тормозить, мы начали копать чтобы понять что пошло не так.
Также если у вас инфра в виртуалках, и надо запускать задачи по крону, затрагивается вопрос мониторинга таких задач. В кубе проще, там есть cronJob и видно статус. В виртуалках для запуска бжкапа из CI и по рассписанию, запустили сервис webhook.
+ мониторинг: SLA, SLO, SLI
+ стандарты по именованию и автоматизация рутины, чтобы не превратить инсталляцию в ад поддержки. У некоторых команд более 15 волтовых групп АД с разными доступами, с разными списками участников, с разными требованиями от ИБ по мониторингу таких групп. Можно было передать управление такими группами на первую линию, но это человеческий фактор и увеличение нагрузки на людей тем что можно автоматизировать.
Я надеюсь что смог раскрыть эти темы, и поделиться опытом, который, возможно, даже окажется полезным другим инженерам при построении их систем.
Ваши цели при совершении действия "не равны" последствиям этих действий. Тинькофф банк - коммерческая структура, ее цель - обогащение собственников банка, Тинькофф банк не будет платить Хабру деньги за право вести корпоративный блог только с той целью, чтобы его технические специалисты могли поделиться своим ценным опытом с комьюнити.
Цель блога - реклама: прямая (привлечение клиентов в нишевой аудитории) или косвенная (создание положительного эмоционального образа бренда). Последствия вашей статьи - больше потенциальных жертв по всей видимости нечистоплотного банка.
Если мне приходится объяснять столь очевидные вещи, какие выводы я должен сделать относительно вашей персоналии? Я вижу две альтернативы: или человек умственно отсталый, или у него у самого "рыльце в пушку". Подскажите мне третью, если я ошибаюсь.
Можно вопрос по существу статьи, а не по принадлежности автора к конкретной организации?
Я правильно понимаю что у вас "модуль в Ansible" получает токен с правами генерации любых объектов - будь то хранилище секретов, политикf доступа или субъект авторизации? Как в этом случае валидируются "пересекающиеся" имена и как контролируется путь для применения плитик (например к другому хранилищу или к применяемому методу аутентификации)?
Доброго дня,
Про права:
Ansible получает минимально необходимые для его работы права:
* Управление политиками (единственная уз с такими правами на весь кластер)
* Управление Auth Backend и учётками внутри
* Управление Secrets Engine
* Управление некоторыми системными вызовами, например управление аудит устройствами
Про имена объектов:
У каждого проекта свой префикс, добавляемый каждому объекту, что исключает пересечение по именам. Например:
* project1__kv <= SE
* project1__kv-rw <= Policy
* project1__kv-ro <= Policy
* project2__kv <= SE
* project2__transit <= SE
Ansible может запросить список объектов, например примонтированных SE, далее по префиксу понять какие объекты относятся к проекту конфиги которого сейчас применяются. Далее идёт сортировка в 3 списка:
* Удалить, если более не описано в конфигурации
* Обновить, если описано и существует
* Создать, если описано и не существует
Про доступ из одного проекта в другой:
Глобально запрещено обращаться к объектам чужого проекта. Коллеги написали валидатор на Open Policy Agent, который проверяет пути в политиках. Если встречается обращение за рамки своего проекта, кроме некоторых путей, пайплайн не пройдёт.
С бакапами ваулта своеобразно.
Не знаю как с консул-хранилищем, а со встроенным рафтом, когда второй кластер, используемый для распечатывания, вдруг неработоспособен, или вдруг у первого кластера проэкспирился токен ко второму (на leader-ноде), то этот самый первый кластер начинает по API отдавать битые снапшоты.
Никаких ошибок, но: "gzip: raft_snapshot-1655683554067570701.snap: unexpected end of file"
А если попробовать снять снапшот через vault operator raft snapshot save, то:
Error taking the snapshot: incomplete snapshot, unable to read SHA256SUMS.sealed file
Спасибо за статью :) Заинтересовал алгоритм Шамира, загуглила и узнала много нового про криптографию и другие интересные разработки!
Подскажите пожалуйста как вы решаете вопросы аудита?
Штатный аудит слишком громоздкий, он пишет всё подряд. Нам не нужно знать как некий сервис запрашивает секрет раз в несколько минут, но хочется знать какой конкретно пользователь (AD) создал новую версию секрета 8 месяцев назад.
Вы как-то решаете эту задачу?
Ох, прошу прощения за долгий ответ.
Конкретно в компании очень большой и производительный SOC. Все аудит логи важны.
Возможно можно на уровне файлбита или вектора сбрасывать часть аудит логов. Те же токен истёк не самые полезные почти всегда. Особенно если учесть то что он хэшируется прежде чем попасть в лог.
Закинул к себе на доску попробовать сделать инсталляцию на docker-compose с выбрасыванием части аудит логов. Но не смогу по времени сориентировать, т.к. планов много, а времени не оч.
@Loyreni, а как вы выживаете без namespaces (их нет в OSS), используя Vault в рамках всей компании?
Как в Тинькофф запускали HashiCorp Vault