Какой смысл Spring Vault, если токен хранится статически?

Question

Я пытаюсь понять концепцию маркера аутентификации в Spring Vault и как должна выглядеть цепочка развертывания?

Везде, где я читаю, я вижу, что токен аутентификации должен быть предоставлен статически так или иначе, и я не понимаю, как это обеспечивается? если я использую хранилище для безопасного хранения своих секретов, а не просто лежу в файле свойств, то зачем хранить токен в одном?

Когда я только начал читать о Vault, я ожидал фазу "взаимодействия с человеком", когда токен предоставляется в качестве системного аргумента или чего-то еще в самый последний момент перед развертыванием / запуском приложения.

Кроме того, я не понимаю, как Vault может вписаться в полностью автоматизированную цепочку развертывания. Мой Jenkins собирается автоматически при каждом изменении основной ветки и публикует jar-файл и запускает его через ssh на назначенную машину. Из того, что я понимаю в Vault, я не могу публиковать свои приложения, верно?

Answer 1

Ваш пост содержит несколько вопросов, которые в основном касаются доверия.

Какой смысл Spring Vault, если токен хранится статически?

Механизм аутентификации зависит как минимум от:

• ваши политики безопасности
• риск, который вы готовы принять
• усилия, которые вы готовы потратить на стороне оперативников.

В некоторых средах Vault со статическим токеном отлично подходит, тогда как в других сценариях требуется многофакторная аутентификация. Со статическим токеном вы можете использовать один токен для всех ваших приложений / экземпляров приложения или разные токены для каждого приложения / приложения. Таким образом, вы можете заблокировать определенный токен, в то время как другие остаются в силе.

Может быть, рассмотрение вопроса с другой точки зрения может помочь: к какому требованию вы пытаетесь обратиться с помощью Vault? Сколько усилий вы готовы потратить на проблему безопасного внедрения?

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

Как защищен токен аутентификации?

Это зависит от вашего окружения и риска, на который вы готовы пойти. Вы можете предоставить статические токены, вообще говоря, свойство config, любому приложению Java по крайней мере следующими способами:

• Файл свойств
• Переменная среды
• Системное свойство
• Аргумент командной строки
• Подскажите во время запуска приложения

Каждая возможность имеет свои собственные свойства и усилия для реализации. Если ваша среда выполнения / контейнер имеет достаточную (это уровень, который вы определяете) защиту, файл свойств может быть полностью в порядке. Если вы хотите поднять планку безопасности выше, вы можете ввести токен во время запуска приложения с подсказкой.

Я не понимаю, как Vault может вписаться в полностью автоматизированную цепочку развертывания.

Это не совсем вопрос, но, возможно, самое интересное предложение в вашем посте.

Когда вы сегодня развертываете с использованием Jenkins и SSH, это означает, что вы доверяете машине Jenkins и оператору, фактически выполняющему развертывание. В этом случае доверие к Jenkins представляется приемлемым риском, поскольку проверка подлинности вашей среды выполнения является частью вашей настройки Jenkins. Отсюда возникает вопрос: доверяете ли вы своей среде выполнения? До какого уровня вы доверяете этому? Если вы не доверяете своей среде выполнения (т. Е. Среда выполнения разглашает секреты, и непреднамеренные стороны могут легко получить к ней доступ), то у вас могут быть более серьезные проблемы, чем статический токен.