На самом деле много кому было бы не интересно "изучать законодательство в части требований ФСБ к СКЗИ и ФСТЭК к ГИС, КИИ", которые сплошь и рядом имеют двоякое толкование или просто неоднозначности. Вместо этого нужна какая-то уверенность в том, если "я сделаю так и вот так" (к примеру, перейду на использование ГОСТ VPN) то какие-то из этих требований будут выполняться. То есть если мы говорим про защиту канала передачи - у аудитора не возникнет вопрос, почему часть трафика между узлами не защищено после внерения ГОСТ VPN. Если вопрос возникает, то внедрение VPN мало помогает, может быть нужно смотреть в сторону сквозного шифрования.
Есть ли какой-то сертификат соответствия вашей схемы подключения?
Смущает такой момент - между клиентом и шлюзом устанавливается защищённое соединение с помощью ГОСТ. Но, судя по схеме, после терминации на аппаратном шлюзе трафик выходит в сеть Селектел, где перемешивается с трафиком других пользователей. У которых может быть свой VPN. Или вообще может не быть VPN.
Что, кажется, противоречит идее virtual private network - ГОСТ-ом защищена не сеть, а какой-то кусочек на пути следования пакетов. Вырожденный случай - можно на локалхосте клиента пропихивать трафик через VPN, а дальше отправлять по обычным каналам, это же не добавляет нам защиту. Если бы мы считали, что с обоих концов шлюза сеть одной компании - то вопросов кажется нет. Но на одной стороне мультетенантная сеть, а транспорт между клиентами закрыт ГОСТ-ом только на половину.
Думаю многие согласятся, что на данный момент внедрение ГОСТ алгоритмов шифрования проводится компаниями не для обеспечения повышенной безопасности, а для соответствия требованиям законодательства. Так вот, как проверяющие органы относятся к тому, что трафик, прошедший через ГОСТ VPN внутри сети Селектел не защищён ГОСТ VPN? Есть ли какие-то подтверждения, что такой подход действительно "православный"?
Ну не обязательно тераформом. Зачем нужен какой-то кусок кластера, который менеджится не так, как остальные ноды?
Это может быть какая-то виртуалка в облаке, которая потом уничтожается. Или докер -контейнер на машине того, кто проводит инсталляцию. Или бинарь/скрипт, который дёргает ручки api до того момента, когда кластер поднимется, и начнет дергать ручки сам
А что происходит с линиями, которые выпускали, скажем так, предыдущие поколения памяти ddr ddr2 ddr3? Модернизируют безвозвратно? Потому что спроса на старую память нет? Или они за 2-3 года производства изнашиваются в ноль, так, что эксплуатировать невозможно?
Просто для огромного количества продуктов потребительского сегмента вполне подошла бы старая память. Да, там есть проблемы с тем, что для старой памяти нужны старые контроллеры, которые тоже сняты с производства. А под них возможно нужен старый код каких-то библиотек, потому что новый может работать только на новом железе.
Но условные стиральные машинки или мультимедиа автомобилей вполне могли бы работать на чипах (в том числе и памяти) десятилетней давности. Просто их вероятно никто не производит.
Лет 5 назад пользовался провайдером tf для proxmox, было терпимо. Провайдер виртуалки нарезал, диски ширил, даже мигрировал между гиперами. Были некоторые моменты, связанные с тем, что кластер из Проксмоксов - не совсем "кластер", а все же набор гиперов, между которыми виртуалочки нужно переносить. Несколько мешала эта "прибитость" машины к гиперу. Если я через UI мигрировал виртуалку, то тераформ надо было править, и стейт синкать. Но с тех пор проксмокс развился, появились ресурс пулы и SDN. Так что "ну почти VSphere для бедных". Или для гиков. Ну и попроще, чем openstack.
Прям в сердечко. Когда мне было года 4 я залез за радиолу. И видимо испугался, когда не смог вылезти, и толкнул ее перед собой (а может быть испугался потом, когда она упала, или когда родители прибежали). Эта картинка у меня в памяти прям отпечаталась - я стою в углу комнаты, передо мной лежит лицом вниз радиола, а с той стороны стоят папа с мамой, прибежавшие на грохот из соседней комнаты. Итог - у радиолы разбитое стекло (была ли бита моя попа - я не помню).
Это мучило меня много лет. Даже потом, когда радиола была уже совсем не современной и переехала на дачу скорее как подставка под цветок, чем как радиоприемник, любой взгляд на разбитое стекло навевал на меня печаль.
И вот, в возрасте лет 14-15 я похоже стал достаточно самостоятельным, настолько, что нашел какую-то радиомастерскую, и купил там новое (во всяком случае - целое) стекло для Ригонды. И сам его поменял.
Детский гештальт был закрыт. И теперь эта история с разбитым стеклом у Ригонды меня не печалит, а даже наоборот - вызывает теплые воспоминания.
И немного подкручпнный мониторинг (он там есть, довольно расширяемый, только по умолчанию все довольно убого настроено)
И получаем бОльшую часть того, что вы описали, где-то чуть больше, где-то чуть меньше.
Правда там начинаются другие проблемы. Если с 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 (чтобы можно было задать сложность секрета)
Опять более 11 лет? Ну так-то спору нет, просто пора бы писать "более 30 лет", ведь первый релиз был в начале 1996 года, а создаётся он ещё дольше.
требованиям "ФСБ к СКЗИ и ФСТЭК к ГИС, КИИ"
На самом деле много кому было бы не интересно "изучать законодательство в части требований ФСБ к СКЗИ и ФСТЭК к ГИС, КИИ", которые сплошь и рядом имеют двоякое толкование или просто неоднозначности. Вместо этого нужна какая-то уверенность в том, если "я сделаю так и вот так" (к примеру, перейду на использование ГОСТ VPN) то какие-то из этих требований будут выполняться. То есть если мы говорим про защиту канала передачи - у аудитора не возникнет вопрос, почему часть трафика между узлами не защищено после внерения ГОСТ VPN. Если вопрос возникает, то внедрение VPN мало помогает, может быть нужно смотреть в сторону сквозного шифрования.
Есть ли какой-то сертификат соответствия вашей схемы подключения?
Смущает такой момент - между клиентом и шлюзом устанавливается защищённое соединение с помощью ГОСТ. Но, судя по схеме, после терминации на аппаратном шлюзе трафик выходит в сеть Селектел, где перемешивается с трафиком других пользователей. У которых может быть свой VPN. Или вообще может не быть VPN.
Что, кажется, противоречит идее virtual private network - ГОСТ-ом защищена не сеть, а какой-то кусочек на пути следования пакетов. Вырожденный случай - можно на локалхосте клиента пропихивать трафик через VPN, а дальше отправлять по обычным каналам, это же не добавляет нам защиту. Если бы мы считали, что с обоих концов шлюза сеть одной компании - то вопросов кажется нет. Но на одной стороне мультетенантная сеть, а транспорт между клиентами закрыт ГОСТ-ом только на половину.
Думаю многие согласятся, что на данный момент внедрение ГОСТ алгоритмов шифрования проводится компаниями не для обеспечения повышенной безопасности, а для соответствия требованиям законодательства. Так вот, как проверяющие органы относятся к тому, что трафик, прошедший через ГОСТ VPN внутри сети Селектел не защищён ГОСТ VPN? Есть ли какие-то подтверждения, что такой подход действительно "православный"?
Ну не обязательно тераформом. Зачем нужен какой-то кусок кластера, который менеджится не так, как остальные ноды?
Это может быть какая-то виртуалка в облаке, которая потом уничтожается. Или докер -контейнер на машине того, кто проводит инсталляцию. Или бинарь/скрипт, который дёргает ручки api до того момента, когда кластер поднимется, и начнет дергать ручки сам
А что происходит с линиями, которые выпускали, скажем так, предыдущие поколения памяти ddr ddr2 ddr3? Модернизируют безвозвратно? Потому что спроса на старую память нет? Или они за 2-3 года производства изнашиваются в ноль, так, что эксплуатировать невозможно?
Просто для огромного количества продуктов потребительского сегмента вполне подошла бы старая память. Да, там есть проблемы с тем, что для старой памяти нужны старые контроллеры, которые тоже сняты с производства. А под них возможно нужен старый код каких-то библиотек, потому что новый может работать только на новом железе.
Но условные стиральные машинки или мультимедиа автомобилей вполне могли бы работать на чипах (в том числе и памяти) десятилетней давности. Просто их вероятно никто не производит.
Лет 5 назад пользовался провайдером tf для proxmox, было терпимо. Провайдер виртуалки нарезал, диски ширил, даже мигрировал между гиперами. Были некоторые моменты, связанные с тем, что кластер из Проксмоксов - не совсем "кластер", а все же набор гиперов, между которыми виртуалочки нужно переносить. Несколько мешала эта "прибитость" машины к гиперу. Если я через UI мигрировал виртуалку, то тераформ надо было править, и стейт синкать.
Но с тех пор проксмокс развился, появились ресурс пулы и SDN. Так что "ну почти VSphere для бедных". Или для гиков. Ну и попроще, чем openstack.
Мы же Кубернетес там на виртуалочках запускаем? Тогда может сразу сюда https://github.com/k8s-proxmox/cloud-provider-proxmox ?
Прям в сердечко.
Когда мне было года 4 я залез за радиолу. И видимо испугался, когда не смог вылезти, и толкнул ее перед собой (а может быть испугался потом, когда она упала, или когда родители прибежали). Эта картинка у меня в памяти прям отпечаталась - я стою в углу комнаты, передо мной лежит лицом вниз радиола, а с той стороны стоят папа с мамой, прибежавшие на грохот из соседней комнаты. Итог - у радиолы разбитое стекло (была ли бита моя попа - я не помню).
Это мучило меня много лет. Даже потом, когда радиола была уже совсем не современной и переехала на дачу скорее как подставка под цветок, чем как радиоприемник, любой взгляд на разбитое стекло навевал на меня печаль.
И вот, в возрасте лет 14-15 я похоже стал достаточно самостоятельным, настолько, что нашел какую-то радиомастерскую, и купил там новое (во всяком случае - целое) стекло для Ригонды. И сам его поменял.
Детский гештальт был закрыт. И теперь эта история с разбитым стеклом у Ригонды меня не печалит, а даже наоборот - вызывает теплые воспоминания.
На фото блок с батареями прямо на улице. Понятно, что это прототип, но исполнение совсем не уличное. А если вдруг дождь?
Мне почему-то показалось, что вода первым делом будет попадать в место подключения батареи к инвертору (в разъем)
Ну рутину допустим убирает установка 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 (чтобы можно было задать сложность секрета)