Skip to content

Настройка интеграции с Vault

Введение

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

Примечание: следует учитывать, что DQ vault нужен только для хранения кредов, по которым DQ будет осуществлять аутентификацию на источнике, остальное не используется.

Предварительные условия

Должен быть установлен и настроен Vault (сервер + клиент). Подробнее см. здесь: https://developer.hashicorp.com/vault/docs/get-vault.

Примечание: следует учитывать, что DQ пока поддерживает только key-value хранилище Vault v1 (есть еще v2, с ним пока не умеет работать).

Шаг 1. Настройка аутентификации с Vault

Как добавить AppRole, смотрите здесь: https://developer.hashicorp.com/vault/docs/auth/approle.

AppRole должна иметь доступ к директориям, в которых планируется хранить секреты от источников.

Информация о том, в каком виде хранить секрет в Vault и как потом настраивать credentials в source, доступна здесь: https://dq.pages.mts.ru/dq-docs/master/dq/1.%20user_guide/metrics/base/source/#hashicorp-vault.

Пример используемых переменных при настройке:

Шаг 2. Настройка политик доступа

На AppRole должна быть навешана политика, которая выдает доступ к директориям, в которых планируется хранить секреты от источников.

О политиках см. здесь: https://developer.hashicorp.com/vault/docs/concepts/policies.

Определение политик доступа (кто и к каким секретам имеет доступ)

Политики в Vault определяют, какие пользователи, сервисы или системы имеют доступ к определённым секретам. Политики пишутся на HCL (HashiCorp Configuration Language) или JSON.

1. Создание простой политики (чтение/запись секретов)

Допустим, у нас есть путь secret/data/myapp/*, и мы хотим разрешить:

  • dev-team — чтение и запись секретов в myapp/dev/
  • prod-team — только чтение секретов в myapp/prod/

Политика для dev-team (dev-policy.hcl):

path "secret/data/myapp/dev/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Разрешить просмотр метаданных (но не самих секретов из других путей)
path "secret/metadata/myapp/*" {
  capabilities = ["list"]
}

Политика для prod-team (prod-policy.hcl):

path "secret/data/myapp/prod/*" {
  capabilities = ["read", "list"]
}

2. Применение политик в Vault

Создаем политики:

vault policy write dev-policy dev-policy.hcl
vault policy write prod-policy prod-policy.hcl

Назначаем политики методам аутентификации:

  • Для AppRole (механизм для машинного доступа):
vault write auth/approle/role/dev-role policies="dev-policy"
vault write auth/approle/role/prod-role policies="prod-policy"
  • Для LDAP/Userpass (пользовательский доступ):
vault write auth/userpass/users/dev-user password="s3cr3t" policies="dev-policy"

3. Проверка доступа

Тестирование от имени dev-team:

vault login -method=userpass username=dev-user password=s3cr3t
vault kv put secret/myapp/dev/db_password value=12345  # Успешно
vault kv get secret/myapp/prod/api_key  # Ошибка (доступ запрещён)

Шаг 3. Интеграция с HashiCorp Vault: настройка доступа к секретам

1. Конфигурация SOURCE_CREDENTIAL_TYPES

Для работы с секретами через HashiCorp Vault необходимо настроить параметры доступа в формате JSON:

Примечание: в role_id и secret_id просто подставляем значения, полученные при создании AppRole, не через отдельные переменные.

{
  "vault_bigdata": {
    "storage_type": "vault",
    "load_point": "api",
    "options": {
      "role_id": "<role_id>", // подставное значение
      "secret_id": "<secret_id>", // подставное значение
      "url": "<vault_url>", // подставное значение
      "version": 1
    }
  },
  "internal": {
    "storage_type": "internal"
  }
}

2. Описание параметров

Параметр Описание Обязательность
storage_type Тип хранилища: vault для HashiCorp Vault или internal для встроенного хранилища Да
load_point Точка загрузки данных (api для взаимодействия через Vault API) Да
role_id Идентификатор роли AppRole (обычно задается через переменную $VAULT_ROLE_ID) Да
secret_id Секретный ключ роли AppRole (обычно задается через $VAULT_SECRET_ID) Да
url Адрес сервера Vault (например, https://vault.example.com:8200) Да
version Версия API Vault (1 или 2) Да

3. Пример настройки переменных окружения

Есть возможность использовать как внутреннее хранилище секретов, так и vault_bigdata. Подключение настраивается в переменной:

SOURCE_CREDENTIAL_TYPES: {"vault_bigdata": {"storage_type": "vault", "load_point": "api", "options": {"role_id": "$VAULT_ROLE_ID", "secret_id": "$VAULT_SECRET_ID", "url": "$VAULT_URL", "version": 1}}, "internal": {"storage_type": "internal"}}

4. Как это работает?

  1. Пользователь записывает секреты в Vault через CLI, API или веб-интерфейс.
  2. Система аутентифицируется в Vault, используя:
  3. role_id и secret_id (механизм AppRole),
  4. указанный URL сервера Vault.
  5. После успешной аутентификации система получает доступ к секретам.
  6. Секреты используются в соответствии с настроенными политиками доступа.