Фактически, всё, кроме самих секретов, в git пушат те, кто понимает, зачем это им, и когда-то обладали соответствующими правами в самом Vault. Ну и у нас все еще есть код ревью, где овнерами являются компетентные люди. Для попытки, например, запустить tofu apply руками, нужно знать токен для Vault, который известен трем людям.
На счет хранения секретов - я отчасти с Вами согласен, но мы хотели дать возможность быстро доставлять секреты в Vault всем, без необходимости идти в сам Vault и обладать нужными правами. Конкретно нас такой юзкейс полностью устраивает, так как правда ускорил процессы. Но я не претендую на то, что данная статья - истина в последней инстанции.
P.S. Спасибо большое за хороший развернутый комментарий
Нет, не совсем. Ключ для sops лежит в секретах Jenkins, и действительно, люди с правами администратора Jenkins могут получить этот ключ через script console. Но по счастливому стечению обстоятельств, администраторы Jenkins - это те же DevOps, которые раньше руками добавляли секреты в Vault.
В корпоративном менеджере паролей. Сразу отвечаю на логично вытекающий вопрос - хранить все пароли мы там не можем из-за ряда причин, одной из которых является отсутствие нормальной интеграции с ArgoCD. Но этот секрет аналогично можно хранить в Vault, нужно только правильно настроить RBAC.
В данном кейсе (если скрипт упадет из-за ошибки в роли или по другим причинам) достаточно будет перезапустить CI-джобу, ресурс null-resource будет пытаться пересоздаться. Но я, как разработчик всего решения, согласен с тем, что подход не самый оптимальный и в будущих моих планах есть переход на Ansible AWX.
Фактически, всё, кроме самих секретов, в git пушат те, кто понимает, зачем это им, и когда-то обладали соответствующими правами в самом Vault. Ну и у нас все еще есть код ревью, где овнерами являются компетентные люди. Для попытки, например, запустить tofu apply руками, нужно знать токен для Vault, который известен трем людям.
На счет хранения секретов - я отчасти с Вами согласен, но мы хотели дать возможность быстро доставлять секреты в Vault всем, без необходимости идти в сам Vault и обладать нужными правами. Конкретно нас такой юзкейс полностью устраивает, так как правда ускорил процессы. Но я не претендую на то, что данная статья - истина в последней инстанции.
P.S. Спасибо большое за хороший развернутый комментарий
Нет, не совсем. Ключ для sops лежит в секретах Jenkins, и действительно, люди с правами администратора Jenkins могут получить этот ключ через script console. Но по счастливому стечению обстоятельств, администраторы Jenkins - это те же DevOps, которые раньше руками добавляли секреты в Vault.
В корпоративном менеджере паролей. Сразу отвечаю на логично вытекающий вопрос - хранить все пароли мы там не можем из-за ряда причин, одной из которых является отсутствие нормальной интеграции с ArgoCD. Но этот секрет аналогично можно хранить в Vault, нужно только правильно настроить RBAC.
Токен от Vault хранится в нем же, в отдельном маунте. Права на чтение для этого маунта определены через RBAC для ряда сотрудников.
В данном кейсе (если скрипт упадет из-за ошибки в роли или по другим причинам) достаточно будет перезапустить CI-джобу, ресурс null-resource будет пытаться пересоздаться. Но я, как разработчик всего решения, согласен с тем, что подход не самый оптимальный и в будущих моих планах есть переход на Ansible AWX.