От хаоса к порядку: как мы научились управлять Vault через GitOps

[dersoverflow]

в нем будут секреты: логин или пароль от базы данных, ключи для S3-бакета и так далее. Эти секреты желательно спрятать.

а где вы храните секреты от Vault?

Мы в команде используем HashiCorp Vault. Храним там секреты

молодцы! моссад спасибо скажет

[Insane_myRR]

Токен от Vault хранится в нем же, в отдельном маунте. Права на чтение для этого маунта определены через RBAC для ряда сотрудников.

[zolti]

а где храните тот секрет, который отмыкает ваши файлы под sops?

[Insane_myRR]

В корпоративном менеджере паролей. Сразу отвечаю на логично вытекающий вопрос - хранить все пароли мы там не можем из-за ряда причин, одной из которых является отсутствие нормальной интеграции с ArgoCD. Но этот секрет аналогично можно хранить в Vault, нужно только правильно настроить RBAC.

[zolti]

верно ли я понимаю, что администратор вашей среды исполнения, заглянувший в джобу выполнения пайпа, сможет отыскать, то что скрыто под Mask Passwords, потом вскрыть все что под SOPS и в итоге получить доступ ко всем секретам хранящимся в Vault, ведь фактически они все у вас хранятся в гит?

[Insane_myRR]

Нет, не совсем. Ключ для sops лежит в секретах Jenkins, и действительно, люди с правами администратора Jenkins могут получить этот ключ через script console. Но по счастливому стечению обстоятельств, администраторы Jenkins - это те же DevOps, которые раньше руками добавляли секреты в Vault.

[budnikovsergey]

del

[trublast]

Все любят волт и тераформ. Но в описанной схеме не очень удачно то, что имея возможность что-то сделать в гите - получаешь возможность вскрыть волт. Или можешь внедриться на раннер - можешь вскрыть волт.

Во-первых, соглашусь, что вариант, когда политики волта хранятся в гите - абсолютно правильный. Но подгружать их волт должен самостоятельно, проверяя подписи коммитов. Несколько подписей поставить на один коммит гит не дает, но есть обходные решения.
Это можно реализовать например через плагин. И в этот момент понимаешь, что затащить в плагин opentofu с провайдером волта - это оверкилл. Мы в итоге храним в git обычные json волтовые или hcl, без всякого терраформа.

Крайний случай - это когда политики в волт пушит какой-то конкретный человек, который и так имеет доступ изменять политики. Но не раннер, не джоба CI и т.д. Это сильно сужает поверхность потенциальной атаки.

Во-вторых, не совсем понятно зачем хранить сами секреты в гите, если они у вас хранятся в волте. Да еще sops свеху прикручен. Волт вообще-то для того, чтобы секреты НЕ хранить нигде кроме волта, да еще извлекать их точечно и именно в тот момент, когда это необходимо. Версионирование секретов волт поддерживает, историю изменений тоже видно. Бэкапы делать - да проще некуда, можно их потом хоть распечатывать в base64, или в паблик выкладывать, это безопасно. В вашем же случае волт - это не система хранения секретов с политиками доступа, а перевалочный пункт по доставке секретов в кубер. И если это действительно то, для чего используется волт, то тут можно было остановиться например на helm-secrets. Получилось бы примерно тоже самое, но без дополнительной машинерии.

[Insane_myRR]

Фактически, всё, кроме самих секретов, в git пушат те, кто понимает, зачем это им, и когда-то обладали соответствующими правами в самом Vault. Ну и у нас все еще есть код ревью, где овнерами являются компетентные люди. Для попытки, например, запустить tofu apply руками, нужно знать токен для Vault, который известен трем людям.

На счет хранения секретов - я отчасти с Вами согласен, но мы хотели дать возможность быстро доставлять секреты в Vault всем, без необходимости идти в сам Vault и обладать нужными правами. Конкретно нас такой юзкейс полностью устраивает, так как правда ускорил процессы. Но я не претендую на то, что данная статья - истина в последней инстанции.

P.S. Спасибо большое за хороший развернутый комментарий