Кстати, а почему выбрали Starvault для сравнения? Даже если говорить про чисто Российские решения на основе Vault, то он вроде ничем не выделяется, а лично для меня вообще выглядит "импортозамещенной сборкой Openbao". При этом, в отличие от других аналогичных продуктов Россиийских вендоров не имеет публичной версии, то есть обычному инженеру "пощупать" Starvault нельзя, только статьи почитать в интернетах. Например мне тестовую версию получить не удалось, с формы на сайте отвечает робот, и дальше тишина. А выводы про OpenBao я сделал просто сравнив историю релизов OpenBao с историей релизов Starvault на сайте - они повторяют друг друга, один четко за другим.
Кстати, насчёт сравнения хранилище, которые вы провели. Заметил, что в Starvault поддерживается только postgres и raft (file и inmem не в счёт, это больше для разработки), и я думаю причина этого тут. В том же Vault CE выбор куда богаче (другой вопрос - нужно ли это)
Лично я бы с закрытыми глазами сказал, что раз OpenBao работает с Postgres, то и Starvault работает с PostgresPro. Есть конечно шансы, что что-то могли сломать, но сломать там очень сложно. И теми тестами, что вы проводили, этого не проверить.
У меня тоже такое ощущение складывалось, что Vault не умеет "ротировать" секреты, особенно в части kv, но думал, что может у вас какие-то доработки в этой части есть.
Кстати замечу, что динамические секреты, описанные в статье - это не ротация секретов. Это каждый раз создание НОВОЙ ПАРЫ логин/пароль. Ротация, как мне кажется, подразумевает, что старая пара перестанет работать после ротации (хотя на этот счёт могут быть разные мнения). А в вашем примере она перестает работать по TTL
Может быть в вашем случае лучше писать, что "ротация" поддерживается для database static roles? Чтобы не было разночтений и ложных ожиданий.
Просто в вашей табличке с требованиями ГОСТ указано, что Централизованное хранение и Ротация это KV-v2 и Настройка автоматической ротации. А по факту оказывается, что эти два пункта друг с другом вообще никак не связаны и не имеют друг к другу отношения. Секреты сами по себе, лежат в kv. А ротация сама по себе, паролей от БД, а не тех секретов, которые лежат в kv. Из таблицы это совершенно не очевидно.
Приветствую! Часто сталкиваюсь с тем, что в статьях про Vault пишут, что в Vault и его производных поддерживается автоматическая ротация. Но как-то оставляют за скобками, ротация чего, и как она работает. И в вашей статье тоже упоминается "автоматическая ротация".
Можете ли на примере StarVault рассказать, как у вас в продукте работает автоматическая ротация секретов в KV-v2? На каком-то простом примере, вроде такого:
Допустим у меня есть mount kv-v2 который называется dev-secrets. В нем лежат секреты приложения app. Секрет для app доступен по пути /v1/dev-secrets/data/app и представляет из себя json вроде
{ "apikey": "xxx", "dataToken": "yyy" }
Это не пароли от БД, а просто какие-то ключи API, которые я хочу хранить в хранилище для секретов.
Я предполагаю, что у меня в инфраструктуре все приложения, которые пользуются apikey и dataToken, получают эти значения из Vault. То есть, казалось бы, можно автоматически ротировать секреты в хранилище, и приложения будут пользоваться новыми версиями. Прям то самое, про что написано в ГОСТ.
Так вот, как в StarVault можно настроить автоматическую ротацию xxx и yyy? Желательно на основе password policy (чтобы можно было задать сложность секрета)
Если попробовать ответить на вопрос 3, то могу предположить, что 1. "Узким местом" в случае с PG были задержки при передаче данных между узлами, они не нулевые. В случае с boltdb данные обрабатываются в том же процессе и пишутся на локальный диск. Если бы вы разместили pg и vault на одной ноде результат мог бы быть другим. 2. У вас было много запросов, возможно стоило покрутить max_parallel
Еще добавлю, что в наших тестах с raft мы упирались в CPU. Картинка примерно такая: 4 ядра - 3000 rps. 8 ядер - 7000 rps, 16 ядер - 10000 rps. И кажется, что тут больше история не хранилкой, а со всем остальным
Спасибо за статью. Тема Vault-совместимых хранилищ мне очень близка, в связи с чем появилось несколько вопросов.
Вы пробовали сравнить производительность Starvault 1.0.4 например с Openbao 2.0.3? Или с Vault (CE) 1.14.8 ? Есть ли хоть какая-то разница?
Аналогичный вопрос про PostgresPro vs Postgres - не проверяли при прочих равных? Наверняка PostgresPro был выбран вами не просто так. Потому что Postgres как минимум в бесконечность раз дешевле по сравнению с PostgresPro, и какой-то эффект от этого кажется должен быть.
Есть ли какое-то понимание, почему бэкенд на PG медленее? Кажется такое же состояние было и 4 года назад, На Хабре ребята уже описывали эту ситуацию, например в статьях 1 и 2 , и пришли примерно к таким же выводам. Я ожидал в вашей статье увидеть разбор причин, но нет. Мы проводили у себя тестирование с etcd в качестве бэкенда, и получили тоже довольно неплохие результаты, лучше, чем Raft. Хотя "под капотом" и там и там boltdb. И интересно было бы копнуть в причины.
Ну и самый интересный вопрос - Hashicorp Vault Enterprise поддерживает только Raft Storage (boltdb). Как вы думаете, почему? Репликация DR и Perfomance, API с расписанием бэкапов и прочие энерпрайзные штуки доступны только в версии с Raft. И тут непонятно - в том же Starvault они не планируются, или потом нужно будет переезжать с PostgresPro на Raft-хранилку?
Странная привязка в курсе к VSphere, учитывая то, что курс рассчитан российских пользователей, а сайт бродкома с российских адресов даже недоступен. И лицензию не купить. А бесплатная лицензия (для home lab и т.п.) беднее, чем бесплатная у того же Proxmox.
Единственное объяснение - крупные компании в РФ все ещё сидят на VSphere. Но в свете ситуации с лицензиями я думаю у всех уже запущен какой-то процесс замены или даже импортозамещения.
Если нужна защита от такой угрозы - отключите кэш.
Опять же, даже в описанном вами случае будет расшифрована не вся база, а только то, что читали другие клиенты в то время, когда машина была уязвимой. То что не читали - останется зашифрованными. Ведь в предложенном сценации атакующий не может инициировать запросы на чтение произвольных ключей (он получил доступ к хосту, но у него нет токенов доступа в API), и все ещё вынужден довольствоваться теми данными, которые читают другие пользователи.
Можно пофантазировать на тему, как защититься от того, что у вас сливают базу целиком и пытаются ее расшифровать. Так как аудит внешний, который не под контролем атакующего (хотя бы его часть, если мы говорим про внешний hsm или transit), то достаточно сделать в базе несколько ханипотов - ключей, которые обычные приложения никогда не читают, и значит никогда не расшифровывают. Если будет запрос на расшифровку такого ключа - значит происходит попытка дампа базы с расшифровкой, и можно вызывать кавалерию.
Если у вас storage backend это внешняя база, например postgres, то такой аудит можно сделать даже на стороне базы, анализируя select-ы по значению where, или добавив триггер.
То есть если вы даже не защитит есть от того, что данные прочитали, то вы точно узнаете про это. А вот в случае снапшота ВМ, без двойного шифрования, данные могут быть расшифрованы оффлайн, и вы про это не узнаете.
Вы слишком упрощаете. В духе "рисуем круг, рисуем сову"
Во-первых, нужно определиться, какого уровня доступ к кластеру получил этот "кто-то"
Ну ладно, пусть даже самый суперпользовательский.
Далее надо определиться, какие такие пароли он может "тупо стырить". Допустим это пароль для доступа к базе данных. Если сектерт инжектируется в память приложения, то в кубернетес его не существует, поэтому "тырить" из кубов нечего. Если пароль динамический, то "тырить" его смысла не имеет, он действителен для одного подключения (оба этих подхода кстати реализованы в модуле secrets-store-integration кубернетес-платформы Deckhouse)
Единственный вариант - запускать поддельные версии приложений которые будут создавать новые пароли, но вместо подключения к базе будут выводить их, допустим, в логи. Но чтобы запускать эти приложения они должны быть доступны где-то внутри вашего контура с кубами. Но вы можете сделать закрытый контур, в котором есть доступ только к вашему проверенному реджистри. Поэтому Хакер сможет делать в вашем кубе "что угодно" (создавать любые манифесты в api), но запускать сможет только ваши доверенные приложения. Которые конечно же пароли в лог не пишут. То есть систему можно настроить так, что даже имея административный доступ а API куба доступа к данным приложений хакер не получит.
То есть "может делать в кубе что угодно" не равно "может запускать в кубе что угодно".
Но в вашем варианте наверное помимо того, что в хакер имеет суперпользовательский доступ в кластер во входных условиях должно быть, что в этом кластере есть открытый доступ в интернет. Но давайте как-то не будем хакеру сразу не то что все ключи выдавать, а прям двери открытые оставлять. Хоть немножко безопасности у нас же есть? Просто если вообще ничего нет (ни сетевого экрана, ни аудита), то вроде и паролей у вас быть не должно, которые надо хакеру украсть.
Конечно нет какой-то серебряной пули, вроде "включи вот эту настройку и хакер даже имея рут привилегии точно ничего у тебя не украдёт". Но можно сильно ограничить возможности хакера с root. Хотя конечно лучше не доводить дело до получения хакером root.
Ну для начала у вас скорее всего не получится "Запустить свою ВМ и обратиться к вашему первому хранилищу". Почему? 1. Запуск машины не будет "незамеченным". Помимо самого снапшота ВМ для запуска нужны какие-то права на запуск, в конце концов сами ресурсы для запуска (cpu/mem/disk), которые обычно квотированные. 2. Для машины нужен будет какой-то адрес, с которого должен быть доступ до второй машины. И наверное он должен отличаться от адреса, с которым работает оригинальная машина. То есть потенциальная проблема доступа решится банально на уровне сетевых политик. У вас же надеюсь не проходной двор в виртуализации, где кто угодно запускает что угодно, где угодно, и с любыми сетевыми адресами?
А если даже и проходной двор, то есть большая разница между "Унести незаметно снапшот, чтобы его локально разобрать и извлечь данные без взаимодействия с чем либо внутри инфраструктуры" и "Провести активные действия по запуску дубля ВМ, и с нее провести активное сетевое взаимодействие с системой внешнего шифрования, для расшифровки каждого секрета обращаясь в через внешний сервис". Второй вариант как минимум будет зафиксирован в аудит-логах, причем как виртуализации, так и внешнего сервиса шифрования. Что, по хорошему, должно привести к ротации ключей, и вероятно злоумышленник просто не успеет ими воспользоваться.
Понятное дело что сами от себя вы ваши пароли не убережете, но ведь цель не в этом.
Основная идея не в том, что используется двойное шифрование (два "лучше" чем один, три "лучше" чем два и т.д.), а в том, что ключ для "второго типа шифрования" не присутствует в ОС, где запущена СХС (система хранения секретов) ни в каком виде. И таким образом можно закрыть потенциальную проблему возможной несанкционированной расшифровки данных если верхний слой инфраструктуры по отношению к СХС (например, ОС или же еще выше - система виртуализации) будет скомпрометирован.
Получится, только путь, где не тебе платят за работу, а ты платишь за обучение, будет ещё чуть более длинным.
Сейчас для любой работы нужно писать и читать, а раньше для этого были писцы.
А ещё нужно уметь считать. Не в том смысле, что в уме нужно решать квадратные уравнения, находить сумму рядов, или дифференцировать. Но нужно понимать концепцию. Раньше для этого были отдельные специалисты, а теперь может любой школьник (я надеюсь). Но компьютер с этим тоже отлично справляется.
И ведь не пропали после этого сеньоры-математики или сеньоры-писатели.
Я не говорю что это невозможно. Просто это не было целью компании, производящей пылесосы.
Можно было бы сделать все автономно, но денег это не принесет, только усложнение разработки.
И надо признать, что компании-протзводителю действительно интересно собирать такую телеметрию - как часто пылесос включают, сколько квадратных метров в среднем он убирает, как часто возникают ошибки и т.д. На основании этого можно например принять решение, что батарейки можно ставить поменьше. Или наоборот, побольше. Меняют ли щетки после того, как приходит уведомление "пора менять" или нет.
"Безопасный пылесос" можно было бы продавать для гиков и прочих параноиков, если бы они за это платили больше денег. Но большинству людей это не нужно, и они наоборот скорее заплатят за то, что карта их дома бэкапится в облаке, а не за то, чтобы работал пиртупир. То есть если "безопасный пылесос" не приносит денег, то скорее всего делать его не будут.
Пылесос строит карту, чтобы по ней в дальнейшем двигаться, и чтобы в приложении по управлению пылесосом ее можно было использовать. Например дать команду "уборка этой зоны" - и ткнуть в комнату на карте.
Как этот функционал должен работать без передачи карты на сервер? Делать канал p2p между пылесосом и приложением в телефоне? Это не будет работать асинхронно, что приведет к негативному клиентскому опыту.
Например Xiaomi эти карты не только создаёт и отправляет на сервер, но ещё и бэкапит. Если вы двигаете мебель и пылесос что-то там не то найдет, то можно откатить карту на предыдущую. А можно загрузить ее в другой пылесос, и тот не будет долбиться об стены, а сразу будет следовать заданным на карте правилам.
Такое себе расследование, исследователь обнаружил очевидное.
Все любят волт и тераформ. Но в описанной схеме не очень удачно то, что имея возможность что-то сделать в гите - получаешь возможность вскрыть волт. Или можешь внедриться на раннер - можешь вскрыть волт.
Во-первых, соглашусь, что вариант, когда политики волта хранятся в гите - абсолютно правильный. Но подгружать их волт должен самостоятельно, проверяя подписи коммитов. Несколько подписей поставить на один коммит гит не дает, но есть обходные решения. Это можно реализовать например через плагин. И в этот момент понимаешь, что затащить в плагин opentofu с провайдером волта - это оверкилл. Мы в итоге храним в git обычные json волтовые или hcl, без всякого терраформа.
Крайний случай - это когда политики в волт пушит какой-то конкретный человек, который и так имеет доступ изменять политики. Но не раннер, не джоба CI и т.д. Это сильно сужает поверхность потенциальной атаки.
Во-вторых, не совсем понятно зачем хранить сами секреты в гите, если они у вас хранятся в волте. Да еще sops свеху прикручен. Волт вообще-то для того, чтобы секреты НЕ хранить нигде кроме волта, да еще извлекать их точечно и именно в тот момент, когда это необходимо. Версионирование секретов волт поддерживает, историю изменений тоже видно. Бэкапы делать - да проще некуда, можно их потом хоть распечатывать в base64, или в паблик выкладывать, это безопасно. В вашем же случае волт - это не система хранения секретов с политиками доступа, а перевалочный пункт по доставке секретов в кубер. И если это действительно то, для чего используется волт, то тут можно было остановиться например на helm-secrets. Получилось бы примерно тоже самое, но без дополнительной машинерии.
Разработчики рассчитывают на зарплату здесь и сейчас. Может быть и стыдно за продукт, но не за саму работу. Это честная работа, не хуже чем работа судьи, который понимает бредовость какой-то конкретной ситуации, но должен руководствоваться не здравым смыслом, а законом.
Менеджеры рассчитывают на лоббирование со стороны государства - заблокируют (или сильно усложнят использование) телеграмм, ватсап и т.д., и критическая масса людей перетечет в Макс просто потому что он работает. И в итоге Макс будет у всех, но может быть кто-то заведет для него отдельный телефон с выломанной камерой, микрофоном и антенной gps.
Если не передёргивать, то никакого веселья. Я думаю, мы тут все немного передёргиваем, чтобы не было скучнее, а было веселее.
А по сути:
отказ етсд не ведет к немедленной недоступности приложений
Все верно. И отказ волта тоже не ведёт
Отказ одной части не блокирует работы остальных
Отказ волта не блокирует работы csi cni dns kubeapi
который еще и бекапить надо
Это же не проблема. Так или иначе все бэкапить надо, в каком-то виде. Ну кроме наверное аппенд-онли блокчейна, который одновременно неизменяемый и распределенный. Например etcd тоже надо бэкапить. Если не хочешь собирать исчезнувший по какой-то причине кластер из сотен и тысяч репозиториев, а хочешь собрать (хотя бы бОльшую часть) из одного места.
а если все таки подумать
Я не считаю что волт сложный и ненадежный, и это повод от него отказаться, или опасаться использовать. С моей точки зрения волт и etcd - идентичныес точки зрения HA по архитектуре штуки. И может быть даже лучше (если вспомнить энтерпрайзные фичи вроде perfomance replica / dr replica). Только в волте больше возможностей по управлению доступом к ключам, больше способов аутентификации , и шифрованная хранила по умолчанию. По производительности конечно волт в сравнении с etcd проигрывает, но это и понятно - там на порядок больше логики накручено по валилации запроса. Но 10к rps на чтение - вполне держит. И для секретов этого как правило более чем достаточно.
В конце концов, если мы верим, что apiserver + etcd - это надёжная связка, то замените apiserver на vault, и получится такая же надёжная vault + etcd. Просто с другим функционалом. Если кому-то этот функционал не нужен, ну чтож, так бывает. Это как пользоваться postgresql и говорить, что kafka сложная и ещё она ломается, поэтому никаких кафок в проекте быть не должно, и для можно/нужно использовать надёжный проверенный Postgres, он простой и не ломается (хаха, нет)
Любимая тема про поваляшки волта. Я например не очень улавливаю, в чем разница в поваляшках, когда
CSI не может подключить диск и приложение не стартует
Секрет из волта не может извлечься
Кубконтроллер лежит и не создаёт поды
Кубапи лежит и кубконтроллер не знает, что нужно создавать поды
Etcd лежит и непонятно, апиха не работает, поды не создаются
Ингресс лежит, и внешний трафик никуда не роутится
CNI лежит и кубосервисы не работают
Кубднс лежит сервисы не резолвятся
Почему волт лежит какой-то по особенному, не как kubeapi или etcd? Etcd вообще максимально похожий на волт с точки зрения HA - работает только один узел.
Если мы говорим про неправильную конфигурацию vault, так давайте тогда делать неправильную конфигурацию etcd. Что? Не конфигурите etcd по 5 раз на дню? А волт конфигурите? А почему?
Если мы говорим, что волт это ещё одна дополнительная точка отказа, то тут соглашусь. Но тогда давайте будем последовательны в наших опасениях и не будем ходить в сервисы по именам (вдруг днс лежит), не подключать диски (вдруг csi лежит), и хранить конфигурации в oci образе (вдруг кубапи лежит и конфигмапу не забрать). И лучше создавать статик поды через файлы, а то вдруг заклинит API и поды из деплоймента не создадутся. Это максимально надёжно.
Кстати, у инжектора есть режим "не смог извлечь секрет - все равно запусти под". Довольно спорный вариант, но закрывает вопрос "пусть приложение хоть как-то запустится без секрета и может быть оно будет работать"
Ну и про /proc/pid/environment Так запретите доступ к этому интерфейсу ОС. Это же не настоящие файлы. Придется правда ядро немного патчнуть, но что нас остановит?
Добавлю, что сертификат LE ничего толком не удостоверяет.
Только то, что в какой-то момент времени доменное имя указывало на IP адрес, при обращении к которому со стороны сервера LE кто-то отдал верный код.
То есть вы можете даже владеть доменом, но где-то по дороге трафик могут отвернуть (осознанно, или из-за ошибки в bgp) и кто-то другой получит сертификат на ваш домен.
Сертификат LE конечно лучше, чем ничего, но это не очень серьезная гарантия.
Кстати, а почему выбрали Starvault для сравнения? Даже если говорить про чисто Российские решения на основе Vault, то он вроде ничем не выделяется, а лично для меня вообще выглядит "импортозамещенной сборкой Openbao". При этом, в отличие от других аналогичных продуктов Россиийских вендоров не имеет публичной версии, то есть обычному инженеру "пощупать" Starvault нельзя, только статьи почитать в интернетах. Например мне тестовую версию получить не удалось, с формы на сайте отвечает робот, и дальше тишина. А выводы про OpenBao я сделал просто сравнив историю релизов OpenBao с историей релизов Starvault на сайте - они повторяют друг друга, один четко за другим.
Кстати, насчёт сравнения хранилище, которые вы провели. Заметил, что в Starvault поддерживается только postgres и raft (file и inmem не в счёт, это больше для разработки), и я думаю причина этого тут. В том же Vault CE выбор куда богаче (другой вопрос - нужно ли это)
Лично я бы с закрытыми глазами сказал, что раз OpenBao работает с Postgres, то и Starvault работает с PostgresPro. Есть конечно шансы, что что-то могли сломать, но сломать там очень сложно. И теми тестами, что вы проводили, этого не проверить.
Насколько нативная? Без wine работает?
А если использовать wine - это нативно или нет?
У меня тоже такое ощущение складывалось, что Vault не умеет "ротировать" секреты, особенно в части kv, но думал, что может у вас какие-то доработки в этой части есть.
Кстати замечу, что динамические секреты, описанные в статье - это не ротация секретов. Это каждый раз создание НОВОЙ ПАРЫ логин/пароль. Ротация, как мне кажется, подразумевает, что старая пара перестанет работать после ротации (хотя на этот счёт могут быть разные мнения). А в вашем примере она перестает работать по TTL
Может быть в вашем случае лучше писать, что "ротация" поддерживается для database static roles? Чтобы не было разночтений и ложных ожиданий.
Просто в вашей табличке с требованиями ГОСТ указано, что Централизованное хранение и Ротация это KV-v2 и Настройка автоматической ротации. А по факту оказывается, что эти два пункта друг с другом вообще никак не связаны и не имеют друг к другу отношения. Секреты сами по себе, лежат в kv. А ротация сама по себе, паролей от БД, а не тех секретов, которые лежат в kv. Из таблицы это совершенно не очевидно.
Приветствую!
Часто сталкиваюсь с тем, что в статьях про Vault пишут, что в Vault и его производных поддерживается автоматическая ротация. Но как-то оставляют за скобками, ротация чего, и как она работает. И в вашей статье тоже упоминается "автоматическая ротация".
Можете ли на примере StarVault рассказать, как у вас в продукте работает автоматическая ротация секретов в KV-v2? На каком-то простом примере, вроде такого:
Допустим у меня есть mount kv-v2 который называется dev-secrets. В нем лежат секреты приложения app. Секрет для app доступен по пути /v1/dev-secrets/data/app и представляет из себя json вроде
{"apikey": "xxx",
"dataToken": "yyy"
}
Это не пароли от БД, а просто какие-то ключи API, которые я хочу хранить в хранилище для секретов.
Я предполагаю, что у меня в инфраструктуре все приложения, которые пользуются apikey и dataToken, получают эти значения из Vault. То есть, казалось бы, можно автоматически ротировать секреты в хранилище, и приложения будут пользоваться новыми версиями. Прям то самое, про что написано в ГОСТ.
Так вот, как в StarVault можно настроить автоматическую ротацию xxx и yyy? Желательно на основе password policy (чтобы можно было задать сложность секрета)
Тут конечно вопрос, что более нативное - патриции в mysql или расширение timescaledb.
Использовали и то и другое, на довольно больших базах.
При использовании timescaledb могут быть нюансы с резервным копированием (а точнее, с восстановлением)
Выполнение обновление версий постгреса требует бОльших познаний от инженера.
Настройка расширения timescaledb тоже требует большей экспертизы, чем apt intsall mysql-server
Так что если mysql уже с патрициями - я бы 10 раз подумал, прежде чем делать миграцию на постгрес с timescaledb.
Для новых инсталляций - может быть, если не хотите создавать патриции. Но миграция? Зачем?
Если попробовать ответить на вопрос 3, то могу предположить, что
1. "Узким местом" в случае с PG были задержки при передаче данных между узлами, они не нулевые. В случае с boltdb данные обрабатываются в том же процессе и пишутся на локальный диск. Если бы вы разместили pg и vault на одной ноде результат мог бы быть другим.
2. У вас было много запросов, возможно стоило покрутить max_parallel
Еще добавлю, что в наших тестах с raft мы упирались в CPU. Картинка примерно такая: 4 ядра - 3000 rps. 8 ядер - 7000 rps, 16 ядер - 10000 rps. И кажется, что тут больше история не хранилкой, а со всем остальным
Спасибо за статью. Тема Vault-совместимых хранилищ мне очень близка, в связи с чем появилось несколько вопросов.
Вы пробовали сравнить производительность Starvault 1.0.4 например с Openbao 2.0.3? Или с Vault (CE) 1.14.8 ? Есть ли хоть какая-то разница?
Аналогичный вопрос про PostgresPro vs Postgres - не проверяли при прочих равных? Наверняка PostgresPro был выбран вами не просто так. Потому что Postgres как минимум в бесконечность раз дешевле по сравнению с PostgresPro, и какой-то эффект от этого кажется должен быть.
Есть ли какое-то понимание, почему бэкенд на PG медленее? Кажется такое же состояние было и 4 года назад, На Хабре ребята уже описывали эту ситуацию, например в статьях 1 и 2 , и пришли примерно к таким же выводам. Я ожидал в вашей статье увидеть разбор причин, но нет. Мы проводили у себя тестирование с etcd в качестве бэкенда, и получили тоже довольно неплохие результаты, лучше, чем Raft. Хотя "под капотом" и там и там boltdb. И интересно было бы копнуть в причины.
Ну и самый интересный вопрос - Hashicorp Vault Enterprise поддерживает только Raft Storage (boltdb). Как вы думаете, почему? Репликация DR и Perfomance, API с расписанием бэкапов и прочие энерпрайзные штуки доступны только в версии с Raft. И тут непонятно - в том же Starvault они не планируются, или потом нужно будет переезжать с PostgresPro на Raft-хранилку?
Странная привязка в курсе к VSphere, учитывая то, что курс рассчитан российских пользователей, а сайт бродкома с российских адресов даже недоступен. И лицензию не купить. А бесплатная лицензия (для home lab и т.п.) беднее, чем бесплатная у того же Proxmox.
Единственное объяснение - крупные компании в РФ все ещё сидят на VSphere. Но в свете ситуации с лицензиями я думаю у всех уже запущен какой-то процесс замены или даже импортозамещения.
Если нужна защита от такой угрозы - отключите кэш.
Опять же, даже в описанном вами случае будет расшифрована не вся база, а только то, что читали другие клиенты в то время, когда машина была уязвимой. То что не читали - останется зашифрованными. Ведь в предложенном сценации атакующий не может инициировать запросы на чтение произвольных ключей (он получил доступ к хосту, но у него нет токенов доступа в API), и все ещё вынужден довольствоваться теми данными, которые читают другие пользователи.
Можно пофантазировать на тему, как защититься от того, что у вас сливают базу целиком и пытаются ее расшифровать. Так как аудит внешний, который не под контролем атакующего (хотя бы его часть, если мы говорим про внешний hsm или transit), то достаточно сделать в базе несколько ханипотов - ключей, которые обычные приложения никогда не читают, и значит никогда не расшифровывают. Если будет запрос на расшифровку такого ключа - значит происходит попытка дампа базы с расшифровкой, и можно вызывать кавалерию.
Если у вас storage backend это внешняя база, например postgres, то такой аудит можно сделать даже на стороне базы, анализируя select-ы по значению where, или добавив триггер.
То есть если вы даже не защитит есть от того, что данные прочитали, то вы точно узнаете про это. А вот в случае снапшота ВМ, без двойного шифрования, данные могут быть расшифрованы оффлайн, и вы про это не узнаете.
Вы слишком упрощаете. В духе "рисуем круг, рисуем сову"
Во-первых, нужно определиться, какого уровня доступ к кластеру получил этот "кто-то"
Ну ладно, пусть даже самый суперпользовательский.
Далее надо определиться, какие такие пароли он может "тупо стырить". Допустим это пароль для доступа к базе данных. Если сектерт инжектируется в память приложения, то в кубернетес его не существует, поэтому "тырить" из кубов нечего. Если пароль динамический, то "тырить" его смысла не имеет, он действителен для одного подключения (оба этих подхода кстати реализованы в модуле secrets-store-integration кубернетес-платформы Deckhouse)
Единственный вариант - запускать поддельные версии приложений которые будут создавать новые пароли, но вместо подключения к базе будут выводить их, допустим, в логи. Но чтобы запускать эти приложения они должны быть доступны где-то внутри вашего контура с кубами. Но вы можете сделать закрытый контур, в котором есть доступ только к вашему проверенному реджистри. Поэтому Хакер сможет делать в вашем кубе "что угодно" (создавать любые манифесты в api), но запускать сможет только ваши доверенные приложения. Которые конечно же пароли в лог не пишут. То есть систему можно настроить так, что даже имея административный доступ а API куба доступа к данным приложений хакер не получит.
То есть "может делать в кубе что угодно" не равно "может запускать в кубе что угодно".
Но в вашем варианте наверное помимо того, что в хакер имеет суперпользовательский доступ в кластер во входных условиях должно быть, что в этом кластере есть открытый доступ в интернет. Но давайте как-то не будем хакеру сразу не то что все ключи выдавать, а прям двери открытые оставлять. Хоть немножко безопасности у нас же есть? Просто если вообще ничего нет (ни сетевого экрана, ни аудита), то вроде и паролей у вас быть не должно, которые надо хакеру украсть.
Конечно нет какой-то серебряной пули, вроде "включи вот эту настройку и хакер даже имея рут привилегии точно ничего у тебя не украдёт". Но можно сильно ограничить возможности хакера с root. Хотя конечно лучше не доводить дело до получения хакером root.
Ну для начала у вас скорее всего не получится "Запустить свою ВМ и обратиться к вашему первому хранилищу". Почему?
1. Запуск машины не будет "незамеченным". Помимо самого снапшота ВМ для запуска нужны какие-то права на запуск, в конце концов сами ресурсы для запуска (cpu/mem/disk), которые обычно квотированные.
2. Для машины нужен будет какой-то адрес, с которого должен быть доступ до второй машины. И наверное он должен отличаться от адреса, с которым работает оригинальная машина. То есть потенциальная проблема доступа решится банально на уровне сетевых политик. У вас же надеюсь не проходной двор в виртуализации, где кто угодно запускает что угодно, где угодно, и с любыми сетевыми адресами?
А если даже и проходной двор, то есть большая разница между "Унести незаметно снапшот, чтобы его локально разобрать и извлечь данные без взаимодействия с чем либо внутри инфраструктуры" и "Провести активные действия по запуску дубля ВМ, и с нее провести активное сетевое взаимодействие с системой внешнего шифрования, для расшифровки каждого секрета обращаясь в через внешний сервис". Второй вариант как минимум будет зафиксирован в аудит-логах, причем как виртуализации, так и внешнего сервиса шифрования. Что, по хорошему, должно привести к ротации ключей, и вероятно злоумышленник просто не успеет ими воспользоваться.
Понятное дело что сами от себя вы ваши пароли не убережете, но ведь цель не в этом.
Основная идея не в том, что используется двойное шифрование (два "лучше" чем один, три "лучше" чем два и т.д.), а в том, что ключ для "второго типа шифрования" не присутствует в ОС, где запущена СХС (система хранения секретов) ни в каком виде. И таким образом можно закрыть потенциальную проблему возможной несанкционированной расшифровки данных если верхний слой инфраструктуры по отношению к СХС (например, ОС или же еще выше - система виртуализации) будет скомпрометирован.
Получится, только путь, где не тебе платят за работу, а ты платишь за обучение, будет ещё чуть более длинным.
Сейчас для любой работы нужно писать и читать, а раньше для этого были писцы.
А ещё нужно уметь считать. Не в том смысле, что в уме нужно решать квадратные уравнения, находить сумму рядов, или дифференцировать. Но нужно понимать концепцию. Раньше для этого были отдельные специалисты, а теперь может любой школьник (я надеюсь). Но компьютер с этим тоже отлично справляется.
И ведь не пропали после этого сеньоры-математики или сеньоры-писатели.
Я не говорю что это невозможно. Просто это не было целью компании, производящей пылесосы.
Можно было бы сделать все автономно, но денег это не принесет, только усложнение разработки.
И надо признать, что компании-протзводителю действительно интересно собирать такую телеметрию - как часто пылесос включают, сколько квадратных метров в среднем он убирает, как часто возникают ошибки и т.д. На основании этого можно например принять решение, что батарейки можно ставить поменьше. Или наоборот, побольше. Меняют ли щетки после того, как приходит уведомление "пора менять" или нет.
"Безопасный пылесос" можно было бы продавать для гиков и прочих параноиков, если бы они за это платили больше денег. Но большинству людей это не нужно, и они наоборот скорее заплатят за то, что карта их дома бэкапится в облаке, а не за то, чтобы работал пиртупир. То есть если "безопасный пылесос" не приносит денег, то скорее всего делать его не будут.
Пылесос строит карту, чтобы по ней в дальнейшем двигаться, и чтобы в приложении по управлению пылесосом ее можно было использовать. Например дать команду "уборка этой зоны" - и ткнуть в комнату на карте.
Как этот функционал должен работать без передачи карты на сервер? Делать канал p2p между пылесосом и приложением в телефоне? Это не будет работать асинхронно, что приведет к негативному клиентскому опыту.
Например Xiaomi эти карты не только создаёт и отправляет на сервер, но ещё и бэкапит. Если вы двигаете мебель и пылесос что-то там не то найдет, то можно откатить карту на предыдущую. А можно загрузить ее в другой пылесос, и тот не будет долбиться об стены, а сразу будет следовать заданным на карте правилам.
Такое себе расследование, исследователь обнаружил очевидное.
Все любят волт и тераформ. Но в описанной схеме не очень удачно то, что имея возможность что-то сделать в гите - получаешь возможность вскрыть волт. Или можешь внедриться на раннер - можешь вскрыть волт.
Во-первых, соглашусь, что вариант, когда политики волта хранятся в гите - абсолютно правильный. Но подгружать их волт должен самостоятельно, проверяя подписи коммитов. Несколько подписей поставить на один коммит гит не дает, но есть обходные решения.
Это можно реализовать например через плагин. И в этот момент понимаешь, что затащить в плагин opentofu с провайдером волта - это оверкилл. Мы в итоге храним в git обычные json волтовые или hcl, без всякого терраформа.
Крайний случай - это когда политики в волт пушит какой-то конкретный человек, который и так имеет доступ изменять политики. Но не раннер, не джоба CI и т.д. Это сильно сужает поверхность потенциальной атаки.
Во-вторых, не совсем понятно зачем хранить сами секреты в гите, если они у вас хранятся в волте. Да еще sops свеху прикручен. Волт вообще-то для того, чтобы секреты НЕ хранить нигде кроме волта, да еще извлекать их точечно и именно в тот момент, когда это необходимо. Версионирование секретов волт поддерживает, историю изменений тоже видно. Бэкапы делать - да проще некуда, можно их потом хоть распечатывать в base64, или в паблик выкладывать, это безопасно. В вашем же случае волт - это не система хранения секретов с политиками доступа, а перевалочный пункт по доставке секретов в кубер. И если это действительно то, для чего используется волт, то тут можно было остановиться например на helm-secrets. Получилось бы примерно тоже самое, но без дополнительной машинерии.
Разработчики рассчитывают на зарплату здесь и сейчас. Может быть и стыдно за продукт, но не за саму работу. Это честная работа, не хуже чем работа судьи, который понимает бредовость какой-то конкретной ситуации, но должен руководствоваться не здравым смыслом, а законом.
Менеджеры рассчитывают на лоббирование со стороны государства - заблокируют (или сильно усложнят использование) телеграмм, ватсап и т.д., и критическая масса людей перетечет в Макс просто потому что он работает. И в итоге Макс будет у всех, но может быть кто-то заведет для него отдельный телефон с выломанной камерой, микрофоном и антенной gps.
Если не передёргивать, то никакого веселья. Я думаю, мы тут все немного передёргиваем, чтобы не было скучнее, а было веселее.
А по сути:
Все верно. И отказ волта тоже не ведёт
Отказ волта не блокирует работы csi cni dns kubeapi
Это же не проблема. Так или иначе все бэкапить надо, в каком-то виде. Ну кроме наверное аппенд-онли блокчейна, который одновременно неизменяемый и распределенный. Например etcd тоже надо бэкапить. Если не хочешь собирать исчезнувший по какой-то причине кластер из сотен и тысяч репозиториев, а хочешь собрать (хотя бы бОльшую часть) из одного места.
Я не считаю что волт сложный и ненадежный, и это повод от него отказаться, или опасаться использовать. С моей точки зрения волт и etcd - идентичныес точки зрения HA по архитектуре штуки. И может быть даже лучше (если вспомнить энтерпрайзные фичи вроде perfomance replica / dr replica). Только в волте больше возможностей по управлению доступом к ключам, больше способов аутентификации , и шифрованная хранила по умолчанию. По производительности конечно волт в сравнении с etcd проигрывает, но это и понятно - там на порядок больше логики накручено по валилации запроса. Но 10к rps на чтение - вполне держит. И для секретов этого как правило более чем достаточно.
В конце концов, если мы верим, что apiserver + etcd - это надёжная связка, то замените apiserver на vault, и получится такая же надёжная vault + etcd. Просто с другим функционалом. Если кому-то этот функционал не нужен, ну чтож, так бывает. Это как пользоваться postgresql и говорить, что kafka сложная и ещё она ломается, поэтому никаких кафок в проекте быть не должно, и для можно/нужно использовать надёжный проверенный Postgres, он простой и не ломается (хаха, нет)
Любимая тема про поваляшки волта. Я например не очень улавливаю, в чем разница в поваляшках, когда
CSI не может подключить диск и приложение не стартует
Секрет из волта не может извлечься
Кубконтроллер лежит и не создаёт поды
Кубапи лежит и кубконтроллер не знает, что нужно создавать поды
Etcd лежит и непонятно, апиха не работает, поды не создаются
Ингресс лежит, и внешний трафик никуда не роутится
CNI лежит и кубосервисы не работают
Кубднс лежит сервисы не резолвятся
Почему волт лежит какой-то по особенному, не как kubeapi или etcd? Etcd вообще максимально похожий на волт с точки зрения HA - работает только один узел.
Если мы говорим про неправильную конфигурацию vault, так давайте тогда делать неправильную конфигурацию etcd. Что? Не конфигурите etcd по 5 раз на дню? А волт конфигурите? А почему?
Если мы говорим, что волт это ещё одна дополнительная точка отказа, то тут соглашусь. Но тогда давайте будем последовательны в наших опасениях и не будем ходить в сервисы по именам (вдруг днс лежит), не подключать диски (вдруг csi лежит), и хранить конфигурации в oci образе (вдруг кубапи лежит и конфигмапу не забрать). И лучше создавать статик поды через файлы, а то вдруг заклинит API и поды из деплоймента не создадутся. Это максимально надёжно.
Кстати, у инжектора есть режим "не смог извлечь секрет - все равно запусти под". Довольно спорный вариант, но закрывает вопрос "пусть приложение хоть как-то запустится без секрета и может быть оно будет работать"
Ну и про /proc/pid/environment Так запретите доступ к этому интерфейсу ОС. Это же не настоящие файлы. Придется правда ядро немного патчнуть, но что нас остановит?
Добавлю, что сертификат LE ничего толком не удостоверяет.
Только то, что в какой-то момент времени доменное имя указывало на IP адрес, при обращении к которому со стороны сервера LE кто-то отдал верный код.
То есть вы можете даже владеть доменом, но где-то по дороге трафик могут отвернуть (осознанно, или из-за ошибки в bgp) и кто-то другой получит сертификат на ваш домен.
Сертификат LE конечно лучше, чем ничего, но это не очень серьезная гарантия.