Использование Spring Cloud Vault для защиты паролей и т. д. в приложениях Spring Boot?
Я сделал несколько поисков, чтобы защитить все конфиденциальные данные в application.properties, и, наконец, решил использовать Spring Cloud Vault от HashiCorp.
Насколько я вижу, я могу хранить все секреты и т. д. в виде пар ключ-значение в этом механизме. Однако я не мог быть уверен и понять следующие моменты. Не могли бы вы помочь мне, пожалуйста?
Сохраняя все конфиденциальные данные в Vault, я думаю, нам нужно предоставить токен в приложении Spring Boot для доступа к этим данным. Итак, для производственной среды предположим, что я отправляю приложение клиенту, должны ли они предоставлять этот токен через переменные среды? Или есть другие безопасные альтернативы?
Как приложение использует секреты, хранящиеся в Vault? Извлекает ли он их всякий раз, когда это необходимо, или извлекает при запуске, а затем сохраняет их в памяти и т. д., на сервере или в контейнере Docker (на основе конфигурации)?
Ответы 1
Токены хранилища следует вводить как переменные среды. Если у вас есть такая платформа, как k8 или OpenShift, сам токен Vault может храниться как секрет.
Springboot загружает секреты из Vault при запуске.
Вот фрагмент нашего файла шаблона DeploymentConfig:
kind: DeploymentConfig
spec:
strategy:
spec:
containers:
- name: {{ .Release.Name }}
env:
- name: VAULT_API
valueFrom:
secretKeyRef:
name: global-secrets
key: vaultapi
- name: VAULT_TOKEN
valueFrom:
secretKeyRef:
name: global-secrets
key: vaulttoken
Большое спасибо за помощь. Затем, если мы не используем k8 или OpenShift, то мы должны передавать токены для Vault через переменные среды как для dev, так и для prod, верно?
С другой стороны, ссылка кажется полезной, но ее дата старая (24 июня 2016 г.), и мне интересно, есть ли обновленная версия этой оригинальной статьи. Есть идеи?
кстати, нельзя голосовать. проголосуйте, пожалуйста, за вопрос?
Да, разные токены хранилища (и, возможно) для каждой среды. Статья может быть старой, но она все еще работает сегодня в моем хранилище, весне, среде k8.
*и, возможно, URL-адреса для каждой среды
Замечательно... Проголосовал и отмечен как ответ.
На самом деле я ищу правильный пример, который использует Docker с правильной конфигурацией, но, к сожалению, не смог найти. Есть ли у вас какие-либо идеи относительно правильного примера, кроме того, которым вы поделились выше?
Я добавил фрагмент шаблона постоянного тока, который мы используем для получения токена хранилища и т. д. из секретов.
Большое спасибо. Мне интересно, как мне защитить токен, который используется для доступа к хранилищу. Обычно я использую его в файле .env, но при отправке приложения в производственном режиме клиенту, должен ли я заставить их обновить токен и продолжить (токен в файле .env будет использоваться ботом в Docker compose и в приложении ). Обычно я игнорирую файл .env, по этой причине я не понимаю, как мне действовать дальше?
Поместите токен хранилища в хранилище секретов управления кластером (k8 или OpenShift), а не в .env. Следовательно, valueFrom.secretKeyRef.name=global-secrets и valueFrom.secretKeyRef.key=vaulttoken
Хорошо, наконец, вы изменили мое мнение на правильный путь. Но IU не уверена, какую из них легче интегрировать. Итак, для простого приложения для изучения Spring Cloud Vault, какое из них я должен предпочесть для хранения токена хранилища? к8 или опеншифт?
У меня есть план изучить k8, тогда не лучше ли для этих целей использовать k8 вместо OpenShift?
k8 используется более широко. OpenShift — это тонкий слой поверх k8.
Тогда мне обязательно стоит выучить k8 и хранить в нем свой токен при использовании хранилища. Спасибо.
@seenukarthi, у вас есть идеи по этому вопросу, помимо форматирования маркеров?