И немного подкручпнный мониторинг (он там есть, довольно расширяемый, только по умолчанию все довольно убого настроено)
И получаем бОльшую часть того, что вы описали, где-то чуть больше, где-то чуть меньше.
Правда там начинаются другие проблемы. Если с kubernetes на "вы", то все может быть сложно, непонятно. И самое страшное - непонятно что делать, если сломалось. Но так можно про что угодно сказать.
Согласен, что хорошо бы иметь для подстраховки людей, которым точно понятно что делать, когда вам уже ничего непонятно. И наверное как раз за это стоит платить.
Собственно самое интересное начинается с момента, когда ломается то, что вроде бы должно было не ломаться.
У меня есть каверзные вопросы в этом плане - что входит в 85%? Где это зафиксировано?
Давайте придумаем какой-то искусственный кейс.
Например я развернул HA кластер в облаке. А потом начал в нем очень интенсивно апдейтить строки. С точки зрения неискушенного пользователя - количество данных не увеличивается. С точки зрения postgres - появляется огромное количество WAL. Что может привести, например:
к окончанию места на диске под WAL
к тому, что WAL не успевает архивироваться или выгружаться в S3 (если такое есть)
к тому, что реплики отстают
к тому, что невозможно сделать консистентный фулл-бэкап, потому что пока вы копируете WAL - появляются новые WAL
С точки зрения пользователя он делает легитимные операции с БД - апдейтит строку в таблице из одной строки. Да, часто, но почему бы и нет? С точки зрения инфраструктуры и репликации постргеса - такие действия приводят к реальным проблемам.
Так вот, кто получает алерты, что, например, WAL не успевают реплицироваться? И как решаются такие ситуации в целом? Кластер ломается потому что место кончилось? Ваши инженеры бегут добавляют место под WAL? Уведомляете клиента что у него уже сломалось? Или что у него вот-вот сломается потому что он активно пишет? А может вы запрещаете делать асинхронные кластера, чтобы всегда была синхронная репликация, и WAL точно доезжали? Начинаете тротлить запросы? А должен ли пользователь Managed Postgres вообще знать что-то про WAL?
Я уже молчу про классику вроде "я купил тут самый жирный вариант инсталляции, но у меня запрос все равно работает медленно, наверное у вас что-то не так с ..." и далее на выбор: инстансом, с дисками, с iops, с сетью, плохая версия посгреса, вы оверселите ... Погружаетесь в запрос, или просто даете ссылку на свой мониторинг, пусть он ему верит?
Так я же не возражаю. Наоборот, предлагаю улучшения. Идея в том, чтобы без ревью нельзя было вносить изменения, даже будучи администратором сервера git
P.S. у нас в команде сотни серверов postgres. К счастью, пока не тысячи.
Может имелось ввиду, что модуль 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. Для машины нужен будет какой-то адрес, с которого должен быть доступ до второй машины. И наверное он должен отличаться от адреса, с которым работает оригинальная машина. То есть потенциальная проблема доступа решится банально на уровне сетевых политик. У вас же надеюсь не проходной двор в виртуализации, где кто угодно запускает что угодно, где угодно, и с любыми сетевыми адресами?
А если даже и проходной двор, то есть большая разница между "Унести незаметно снапшот, чтобы его локально разобрать и извлечь данные без взаимодействия с чем либо внутри инфраструктуры" и "Провести активные действия по запуску дубля ВМ, и с нее провести активное сетевое взаимодействие с системой внешнего шифрования, для расшифровки каждого секрета обращаясь в через внешний сервис". Второй вариант как минимум будет зафиксирован в аудит-логах, причем как виртуализации, так и внешнего сервиса шифрования. Что, по хорошему, должно привести к ротации ключей, и вероятно злоумышленник просто не успеет ими воспользоваться.
Понятное дело что сами от себя вы ваши пароли не убережете, но ведь цель не в этом.
Основная идея не в том, что используется двойное шифрование (два "лучше" чем один, три "лучше" чем два и т.д.), а в том, что ключ для "второго типа шифрования" не присутствует в ОС, где запущена СХС (система хранения секретов) ни в каком виде. И таким образом можно закрыть потенциальную проблему возможной несанкционированной расшифровки данных если верхний слой инфраструктуры по отношению к СХС (например, ОС или же еще выше - система виртуализации) будет скомпрометирован.
На фото блок с батареями прямо на улице. Понятно, что это прототип, но исполнение совсем не уличное. А если вдруг дождь?
Мне почему-то показалось, что вода первым делом будет попадать в место подключения батареи к инвертору (в разъем)
Ну рутину допустим убирает установка cnpg operator, одной строкой
И немного подкручпнный мониторинг (он там есть, довольно расширяемый, только по умолчанию все довольно убого настроено)
И получаем бОльшую часть того, что вы описали, где-то чуть больше, где-то чуть меньше.
Правда там начинаются другие проблемы. Если с kubernetes на "вы", то все может быть сложно, непонятно. И самое страшное - непонятно что делать, если сломалось. Но так можно про что угодно сказать.
Согласен, что хорошо бы иметь для подстраховки людей, которым точно понятно что делать, когда вам уже ничего непонятно. И наверное как раз за это стоит платить.
Собственно самое интересное начинается с момента, когда ломается то, что вроде бы должно было не ломаться.
У меня есть каверзные вопросы в этом плане - что входит в 85%? Где это зафиксировано?
Давайте придумаем какой-то искусственный кейс.
Например я развернул HA кластер в облаке. А потом начал в нем очень интенсивно апдейтить строки. С точки зрения неискушенного пользователя - количество данных не увеличивается. С точки зрения postgres - появляется огромное количество WAL. Что может привести, например:
к окончанию места на диске под WAL
к тому, что WAL не успевает архивироваться или выгружаться в S3 (если такое есть)
к тому, что реплики отстают
к тому, что невозможно сделать консистентный фулл-бэкап, потому что пока вы копируете WAL - появляются новые WAL
С точки зрения пользователя он делает легитимные операции с БД - апдейтит строку в таблице из одной строки. Да, часто, но почему бы и нет?
С точки зрения инфраструктуры и репликации постргеса - такие действия приводят к реальным проблемам.
Так вот, кто получает алерты, что, например, WAL не успевают реплицироваться? И как решаются такие ситуации в целом? Кластер ломается потому что место кончилось? Ваши инженеры бегут добавляют место под WAL? Уведомляете клиента что у него уже сломалось? Или что у него вот-вот сломается потому что он активно пишет? А может вы запрещаете делать асинхронные кластера, чтобы всегда была синхронная репликация, и WAL точно доезжали? Начинаете тротлить запросы? А должен ли пользователь Managed Postgres вообще знать что-то про WAL?
Я уже молчу про классику вроде "я купил тут самый жирный вариант инсталляции, но у меня запрос все равно работает медленно, наверное у вас что-то не так с ..." и далее на выбор: инстансом, с дисками, с iops, с сетью, плохая версия посгреса, вы оверселите ... Погружаетесь в запрос, или просто даете ссылку на свой мониторинг, пусть он ему верит?
Так я же не возражаю. Наоборот, предлагаю улучшения. Идея в том, чтобы без ревью нельзя было вносить изменения, даже будучи администратором сервера git
P.S. у нас в команде сотни серверов postgres. К счастью, пока не тысячи.
И через подпись коммита с помощью PGP кворумом из доверенного количества аудиторов )
Тут вероятно вопрос терминологии
Может имелось ввиду, что модуль 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. Для машины нужен будет какой-то адрес, с которого должен быть доступ до второй машины. И наверное он должен отличаться от адреса, с которым работает оригинальная машина. То есть потенциальная проблема доступа решится банально на уровне сетевых политик. У вас же надеюсь не проходной двор в виртуализации, где кто угодно запускает что угодно, где угодно, и с любыми сетевыми адресами?
А если даже и проходной двор, то есть большая разница между "Унести незаметно снапшот, чтобы его локально разобрать и извлечь данные без взаимодействия с чем либо внутри инфраструктуры" и "Провести активные действия по запуску дубля ВМ, и с нее провести активное сетевое взаимодействие с системой внешнего шифрования, для расшифровки каждого секрета обращаясь в через внешний сервис". Второй вариант как минимум будет зафиксирован в аудит-логах, причем как виртуализации, так и внешнего сервиса шифрования. Что, по хорошему, должно привести к ротации ключей, и вероятно злоумышленник просто не успеет ими воспользоваться.
Понятное дело что сами от себя вы ваши пароли не убережете, но ведь цель не в этом.
Основная идея не в том, что используется двойное шифрование (два "лучше" чем один, три "лучше" чем два и т.д.), а в том, что ключ для "второго типа шифрования" не присутствует в ОС, где запущена СХС (система хранения секретов) ни в каком виде. И таким образом можно закрыть потенциальную проблему возможной несанкционированной расшифровки данных если верхний слой инфраструктуры по отношению к СХС (например, ОС или же еще выше - система виртуализации) будет скомпрометирован.