Надежно хранить секреты приложения Spring Boot в HashiCorp Vault?

Question

Я прочитал следующий учебник: Конфигурация Vault

Хорошо, мы установили сервер Vault и поместили 2 пары секретных свойств:

$ vault kv put secret/gs-vault-config example.username=demouser example.password=demopassword
$ vault kv put secret/gs-vault-config/cloud example.username=clouduser example.password=cloudpassword

Spring boot application имеет следующие свойства (bootstrap.properties):

spring.application.name=gs-vault-config
spring.cloud.vault.token=00000000-0000-0000-0000-000000000000
spring.cloud.vault.scheme=http
spring.cloud.vault.kv.enabled=true

Таким образом, на основе spring.cloud.vault.token приложение может считывать защищенные свойства (имя и пароль), но spring.cloud.vault.token хранится в незащищенном месте - bootstrap.properties, который хранится в хранилище кода. Не могли бы вы объяснить, почему это безопасно?

PS

Как мы выяснили, это небезопасно. Как сделать это безопасно? Я понимаю, что может быть несколько решений, чтобы сделать его безопасным, но мне достаточно одного упрощенного примера.

Answer 1

Не могли бы вы объяснить, почему это безопасно?

Ответ заключается в том, что это НЕ безопасно ... если вы делаете это таким образом. Например, справочное руководство Spring Vault гласит:

«Внимательно рассмотрите ваши требования безопасности. Аутентификация токена Stati c подойдет, если вы хотите быстро начать работу с Vault, но токен stati c больше не защищен. Любое раскрытие непреднамеренным сторонам позволяет использовать Vault со связанными ролями токенов. "

Вы должны либо защитить свое состояние c токены или только предоставьте им доступ к «секретам» в хранилище, которые вы рады быть широко известными.

В качестве альтернативы, пусть ваше приложение использует аутентифицированный метод для генерации краткосрочных Dynami c токены.

---

Как я понимаю, первоначальная проблема - плохо хранить пароли в файле application.properties на Github.

И сохранение stati c Маркер хранилища в файле application.properties на Github одинаково плох.

В чем разница?

Разницы почти нет ¹ . Это просто неправильный способ использования Vault.

---

^{1 - Есть небольшое преимущество в том, что вы можете сделать недействительным токен, если обнаружите его утечку случайно. Но это не значит, что разумно публиковать sh преднамеренно.}

---

Так как же вы делаете это безопасно?

Во-первых, вы НЕОБХОДИМО обезопасить машины, где будут использоваться секреты. Даже если вы не собираетесь хранить настоящие секреты на диске, вам нужно будет хранить разные секреты (надежно) на каждой из ваших машин, чтобы они могли аутентифицировать себя в том месте, где хранятся настоящие секреты.

Вот пример использования Chef.

1. Установите безопасный сервер Chef, который хранит конфиги для ваших машин; т.е. рецепты для всего, что должно быть установлено, описания узлов, чтобы сказать, какие рецепты применять, и т. д. c.

2. Когда вы bootstrap машина как узел, пара ключей генерируется для машины и регистрируется на сервере Chef. Пара ключей также хранится на компьютере и должна храниться надежно.

3. Затем вы используете клиент Chef для запуска рецептов, которые устанавливают и настраивают ваш сервер.

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

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

Answer 2

Отвечая на ваши вопросы

Не могли бы вы объяснить, почему это безопасно?

Это небезопасно! Никогда не оставляйте простой секрет в управлении исходным кодом.

Как мы выяснили, это небезопасно. Как сделать это безопасным?

Некоторые способы повысить безопасность:

• Использовать переменные среды вместо файла свойств;
• Ограничить доступ в сети Уровень сервера Vault только для серверов рабочей нагрузки. Это гарантирует, что никто за пределами этой сети не сможет обменять токен;
• Vault работает, генерируя реальные, но временные учетные данные при каждом использовании токена. По возможности уменьшите область действия реальных учетных данных до уровня «только для чтения»;
• Регулярно вращайте токен.

---

Относительно особенностей Spring

Свойства bootstrap должны содержать только некритические свойства. Для критических свойств их можно передать приложению с помощью переменных среды.

spring.cloud.vault.token = ${SPRING_CLOUD_VAULT_TOKEN}

---

Сводка

Остается вопрос " Кто охраняет ключи? ". Но Vault Token на самом деле служит для защиты реальных конфиденциальных данных. В случае утечки токена хранилища вы можете аннулировать только токен.

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

Answer 3

Хранение spring.cloud.vault.token в application.properties, зарегистрированном в VCS (например, Git), может поставить под угрозу все секреты, хранящиеся в Vault.

Решение состоит не в том, чтобы хранить токен Vault в application.properties как простой текст. Есть несколько вариантов.

Удалить токен Vault из application.properties

Просто удалите spring.cloud.vault.token из application.properties и предоставьте его через системное свойство -Dspring.cloud.vault.token=00000000-0000-0000-0000-000000000000 (при запуске приложения) или переменная окружения SPRING_CLOUD_VAULT_TOKEN. Переменная окружения особенно удобна, если вы используете контейнеры (Docker или Kubernetes).

Храните зашифрованный токен Vault в application.properties

Вы можете сохранить свойство spring.cloud.vault.token в application.properties, если оно в зашифрованном виде.

Spring Cloud Config поддерживает расшифровку свойств со значениями, начинающимися с {cipher}:

spring.cloud.vault.token={cipher}encrypted_vault_token

Чтобы использовать свойства шифрования и дешифрования, вам понадобятся следующие зависимости (пример для Gradle):

implementation 'org.springframework.cloud:spring-cloud-context:2.2.2.RELEASE'
implementation 'org.bouncycastle:bcprov-jdk15on:1.64'

Symmetri c шифрование

Самый простой способ зашифровать свойства - это использовать шифрование симметрии c.

Поднимитесь с ключом симметрии c (например, s3cr3t).

Для шифрования токена Vault вы можете использовать Spring Boot CLI с Spring Boot Cloud CLI :

curl "https://repo.spring.io/release/org/springframework/boot/spring-boot-cli/2.2.2.RELEASE/spring-boot-cli-2.2.2.RELEASE-bin.tar.gz" -o spring-boot-cli-bin.tar.gz
tar -xf spring-boot-cli-bin.tar.gz
cd spring-2.2.2.RELEASE
bin/spring install org.springframework.cloud:spring-cloud-cli:2.2.1.RELEASE

bin/spring encrypt 00000000-0000-0000-0000-000000000000 --key s3cr3t
# 507cd1614682535ab8237b448ca73dc74058d3ae9145d63a7381ee67f3046eb1598da6960abdbf2dbf22c47206db5222e45fc74fd6122bc707b61c62f5051e0f

bin/spring decrypt 507cd1614682535ab8237b448ca73dc74058d3ae9145d63a7381ee67f3046eb1598da6960abdbf2dbf22c47206db5222e45fc74fd6122bc707b61c62f5051e0f --key s3cr3t
# 00000000-0000-0000-0000-000000000000

Передать ключ симметрии c приложению в переменной среды ENCRYPT_KEY.

Ключ шифрования Symmetri c никогда не должен проверяться в VCS.

Asymmetri c шифрование

Рассмотрим r asymmetri c шифрование с использованием publi c и пары секретных ключей в качестве более безопасной альтернативы шифрованию симметри c.

Вместо ключа шифрования симметрии c необходимо создать хранилище ключей (используя keytool утилита, поставляемая с JDK или openssl).

В bootstrap.properties укажите следующие свойства:

• encrypt.keyStore.location
• encrypt.keyStore.password
• encrypt.keyStore.alias
• encrypt.keyStore.type

Хранилище ключей должно быть установлено в месте, указанном в encrypt.keyStore.location, и никогда не регистрироваться в VCS .

Кроме того, пароль, который лучше разблокирует хранилище ключей для передачи в ENCRYPT_KEYSTORE_PASSWORD переменную среды.

Подробнее о управлении ключами в Spring Cloud Config.