Может имелось ввиду, что модуль conntrack не обязателен. Может это и так, если таблицу хранить в другом месте, или маппинг генерировать по правилам.
Но если генерировать по правилам, то это все ещё динамический NAT, или уже нет? Опять вопрос терминологии.
Давайте нафантазируем NAT для сети класса C без conntrack.
Вариант 1: значение port 2 байта, 0-65535. Представим, что старшая часть + 1024 это исходный порт, а младшая часть это младший байт исходного IP адреса. Тогда по такой статической таблице можно NATить сетку класса С, на 256 соединений в каждый адрес. Правда на source хостах придется ограничить диапазон исходящих портов, но как-то оно работать будет.
Вариант 2: гипотетически можно мапить служебное поле IP пакета (например, ToS?) в source адрес. Это 8 бит. При условии, что его не модифицируют и сохранят при отправке пакета обратно (а это не гарантируется) , то можно организовать NAT не 1:1, а, если повезёт 1:256 (тут надо исследовать, не все ToS могут быть валидны, но я уверен, что 1:2 сделать можно)
Если уж начали говорить про CNI, таких как cilium или calico, то "магии" там полно. Потому что они для обработки сетевого трафика используют eBPF, и логика работы может меняться от версии к версии CNI. При этом "почему не работает" вы сможете узнать только почитав исходники CNI. И если повезёт, найдете там ответ.
Яркий пример - cilium дропает пакеты vrrp. Поэтому не работают решения, которые его используют, например keepalived. То есть вы не можете сделать с помощью keepalived плавающий ip между двумя куб-нодами, и приходится использовать другие решения.
До момента с eBPF действительно сеть в linux работает практически одинаково, что на железке, что на виртуалке, что в контейнере. Потому что пакеты обрабатывает код ядра. А когда подключается eBPF - там уже неожиданности могут быть на каждом шагу, потому что в "стройную и понятную" работу ядра, что называется - "без магии", вмешиваются bpf-программы.
Кстати, а почему выбрали 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.
Тут вероятно вопрос терминологии
Может имелось ввиду, что модуль conntrack не обязателен. Может это и так, если таблицу хранить в другом месте, или маппинг генерировать по правилам.
Но если генерировать по правилам, то это все ещё динамический NAT, или уже нет? Опять вопрос терминологии.
Давайте нафантазируем NAT для сети класса C без conntrack.
Вариант 1: значение port 2 байта, 0-65535. Представим, что старшая часть + 1024 это исходный порт, а младшая часть это младший байт исходного IP адреса. Тогда по такой статической таблице можно NATить сетку класса С, на 256 соединений в каждый адрес. Правда на source хостах придется ограничить диапазон исходящих портов, но как-то оно работать будет.
Вариант 2: гипотетически можно мапить служебное поле IP пакета (например, ToS?) в source адрес. Это 8 бит. При условии, что его не модифицируют и сохранят при отправке пакета обратно (а это не гарантируется) , то можно организовать NAT не 1:1, а, если повезёт 1:256 (тут надо исследовать, не все ToS могут быть валидны, но я уверен, что 1:2 сделать можно)
Если уж начали говорить про CNI, таких как cilium или calico, то "магии" там полно. Потому что они для обработки сетевого трафика используют eBPF, и логика работы может меняться от версии к версии CNI. При этом "почему не работает" вы сможете узнать только почитав исходники CNI. И если повезёт, найдете там ответ.
Яркий пример - cilium дропает пакеты vrrp. Поэтому не работают решения, которые его используют, например keepalived. То есть вы не можете сделать с помощью keepalived плавающий ip между двумя куб-нодами, и приходится использовать другие решения.
До момента с eBPF действительно сеть в linux работает практически одинаково, что на железке, что на виртуалке, что в контейнере. Потому что пакеты обрабатывает код ядра. А когда подключается eBPF - там уже неожиданности могут быть на каждом шагу, потому что в "стройную и понятную" работу ядра, что называется - "без магии", вмешиваются bpf-программы.
Он попал в сеть принтера. После чего открыл дверь отмычкой. Зачем попадал в сеть принтера?
Кто сказал, что она доверенная? Как правило из сети принтеров никуда не попасть, ведь принтеры никуда не ходят.
Помещения без камер. Без датчиков движения. Двери без датчиков открытия. Где? В банке? Серьезно? На производстве резиновых галош и то не так.
Можно сделать скидку, что сигнализацию отключили из-за клининга офиса. Но что значит "уборщики ... или уже закончили"? И не включили сигнализацию?
Не совсем понял, куда он пшикал холодным воздухом. В щель между дверями?
Что за история с проёмом в стене? Он проломил там стену и пролезьв него? Проем был сквозной?
Мутная история, похоже на сказку.
Кстати, а почему выбрали 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.