Рубрики
Без рубрики

Вступление к Spring Cloud Vault

Краткое введение в Spring Cloud Vault, показывающее, как извлекать учетные данные и управлять ими в приложениях Spring.

Автор оригинала: Philippe Sevestre.

1. Обзор

В этом уроке мы покажем, как мы можем использовать хранилище Hashicorp в приложениях Spring Boot для защиты конфиденциальных данных конфигурации.

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

2. Весеннее Облачное хранилище

Spring Cloud Vault-это относительно недавнее дополнение к стеку Spring Cloud, которое позволяет приложениям прозрачно получать доступ к секретам, хранящимся в экземпляре хранилища .

В общем, миграция в хранилище-это очень простой процесс: просто добавьте необходимые библиотеки и добавьте несколько дополнительных свойств конфигурации в наш проект, и мы будем готовы к работе. Никаких изменений кода не требуется!

Это возможно, потому что он действует как высокоприоритетный Источник свойств , зарегистрированный в текущей Среде .

Таким образом, Spring будет использовать его всякий раз, когда требуется свойство. Примеры включают Источник данных свойства, Свойства конфигурации, и так далее.

3. Добавление Spring Cloud Vault в проект Spring Boot

Чтобы включить библиотеку spring-cloud-vault в проект Spring Boot на основе Maven, мы используем связанный артефакт starter , который извлекает все необходимые зависимости.

Помимо основного starter, мы также включим spring-vault-config-databases , который добавляет поддержку динамических учетных данных базы данных:


    org.springframework.cloud
    spring-cloud-starter-vault-config


    org.springframework.cloud
    spring-cloud-vault-config-databases

Последнюю версию Spring Cloud Vault starter можно загрузить с Maven Central.

3.1. Базовая конфигурация

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

Мы делаем это, предоставляя необходимую информацию в bootstrap.yml или bootstrap.properties :

# bootstrap.yml
spring:
  cloud:
    vault:
      uri: https://localhost:8200
      ssl:
        trust-store: classpath:/vault.jks
        trust-store-password: changeit

Свойство spring.cloud.vault.uri указывает на адрес API хранилища. Поскольку наша тестовая среда использует HTTPS с самозаверяющим сертификатом, нам также необходимо предоставить хранилище ключей, содержащее его открытый ключ.

Обратите внимание, что в этой конфигурации нет данных аутентификации . В простейшем случае, когда мы используем фиксированный токен, мы можем передать его через системное свойство spring.cloud.vault.token или переменную среды. Этот подход хорошо работает в сочетании со стандартными механизмами конфигурации облака, такими как карты конфигурации Kubernetes или секреты Docker.

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

4. Использование бэкенда общих секретов

Мы используем Общий секретный сервер для доступа к неверсированным секретам, хранящимся в виде пар ключ-значение в хранилище .

Предполагая , что у нас уже есть зависимость spring-cloud-starter-vault-config в нашем classpath , все, что нам нужно сделать, это добавить несколько свойств в файл конфигурации bootstrap.yml приложения:

spring:
  cloud:
    vault:
      # other vault properties omitted ...
      generic:
        enabled: true
        application-name: fakebank

Свойство application-name в этом случае необязательно. Если не указано, Spring примет значение стандартного spring.application.имя вместо этого.

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

@Autowired Environment env;
public String getFoo() {
    return env.getProperty("foo");
}

Как мы видим, сам код ничего не знает о хранилище, и это хорошо! Мы все еще можем использовать фиксированные свойства в локальных тестах и переключаться на хранилище по своему усмотрению, просто включив одно свойство в bootstrap.yml .

4.1. Примечание по профилям пружин

Если доступно в текущей среде , Spring Cloud Vault будет использовать доступные имена профилей в качестве суффикса, добавляемого к указанному базовому пути, в котором будут выполняться поиск пар ключ/значение|/.

Он также будет искать свойства в настраиваемом пути приложения по умолчанию (с суффиксом профиля и без него), чтобы мы могли иметь общие секреты в одном месте. Используйте эту функцию с осторожностью!

Подводя итог, если production профиль приложения out fake bank активен, Spring Vault будет искать свойства, хранящиеся по следующим путям:

  1. секрет/ поддельный банк /производство (более высокий приоритет)
  2. секрет/ фальшивый банк
  3. секрет/применение/производство
  4. секрет/приложение (более низкий приоритет)

В предыдущем списке application – это имя, которое Spring использует в качестве дополнительного местоположения по умолчанию для секретов. Мы можем изменить его с помощью свойства spring.cloud.vault.generic.default-context .

Свойства, хранящиеся под самым определенным путем, будут иметь приоритет над другими. Например, если одно и то же свойство foo доступно в разделе пути выше, то порядок приоритета будет следующим:

5. Использование Секретного бэкенда базы данных

Модуль серверной части базы данных позволяет приложениям Spring использовать динамически генерируемые учетные данные базы данных, созданные Vault . Spring Vault вводит эти учетные данные в стандартные spring.datasource.username и spring.datasource.password свойства, чтобы они могли быть выбраны обычными DataSource s.

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

Чтобы использовать учетные данные базы данных, созданные хранилищем, в нашем приложении Spring, spring-cloud-vault-config-databases должен присутствовать в пути к классам проекта вместе с соответствующим драйвером JDBC.

Нам также необходимо включить его использование в нашем приложении, добавив несколько свойств в наш bootstrap.yml:

spring:
  cloud:
    vault:
      # ... other properties omitted
      database:
        enabled: true
        role: fakebank-accounts-rw

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

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

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

Теперь давайте посмотрим на эту интеграцию в действии. Следующий фрагмент кода получает новое соединение с базой данных из управляемого Spring источника данных :

Connection c = datasource.getConnection();

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

6. Заключение

В этом руководстве мы показали, как интегрировать Vault с Spring Boot с помощью библиотеки Spring Vault. Мы рассмотрели два распространенных варианта использования: общие пары ключ/значение и динамические учетные данные базы данных.

Пример проекта, содержащего все необходимые зависимости, тесты интеграции и сценарии установки хранилища, доступен на GitHub .

Читайте ещё по теме: