Перейти к содержанию

8. Продвинутые темы

Цель — понять возможности уровня Middle+ / Senior, которые обычно доступны в Vault Enterprise (и отдельно — hardening с HSM и FIPS). В Vault OSS многие пункты ниже отсутствуют; для open-source заложите изоляцию через отдельные кластеры и строгие политики. Ниже — смысл функций, production-замечания и короткие примеры CLI/конфигурации.

Мультитенантность: namespaces (Enterprise)

Namespace — логическая изоляция путей, политик, auth methods и audit внутри одного кластера: разные команды/продукты без смешивания path в корне.

Плюс Риск / внимание
Единый кластер, разделение административных границ Сложнее ментальная модель; ошибка в parent namespace может расширить blast radius
Делегирование admin внутри ветки Нужны чёткие runbook и контроль ключей репликации (если репликация включена)

Примеры CLI

# Создать пространство имён (контекст — кластер с лицензией Enterprise)
vault namespace create team-payments

# Список (из родительского контекста)
vault namespace list

# Операции внутри namespace без смены контекста (-namespace)
vault kv put -namespace=team-payments secret/config api_url="https://api.example"

# Или установить переменную окружения для сеанса
export VAULT_NAMESPACE=team-payments
vault kv get secret/config

Best practices:

  • именование namespaces по устойчивым идентификаторам (команда/департамент), не по временным проектам;
  • политики в духе least privilege в каждом namespace; центральный break-glass только у платформенной команды;
  • аудит: проверить, что устройства audit покрывают нужные ветки (см. документацию по audit и namespaces для вашей версии).

Репликация (Enterprise)

Два основных паттерна (терминология и детали — в актуальной документации HashiCorp):

Вид Назначение Типичный production-сценарий
Performance replication Вторичные кластеры ближе к потребителям, чтение с низкой задержкой Регионы с приложениями, тяжёлый read-path к Vault
DR replication Аварийная копия для переключения при потере primary DR-регион, редкие failover-учения

Различия на уровне эксплуатации

  • Performance secondaries обслуживают запросы согласно лицензии и топологии; данные «следуют» за primary.
  • DR secondary обычно в режиме, близком к «горячему standby» для переключения — не путайте с обычным масштабированием Raft внутри одного региона.

Best practices:

  • отдельные runbook на failover и обратное переключение;
  • мониторинг лаг репликации и ошибок sync;
  • согласовать с безопасностью хранение recovery/admin процедур для вторичного сайта.

Комментарий: конкретные команды vault write sys/replication/... зависят от версии и уже выбранной topologии — при внедрении ориентируйтесь на официальный tutorial Replication для вашей ветки.

HSM: интеграция (PKCS#11 seal)

HSM используют для хранения ключевого материала seal в аппаратном модуле: усложняется извлечение master key с хоста.

Идея в конфигурации

Часто применяют PKCS#11-библиотеку поставщика HSM и seal stanza в vault.hcl (имена полей зависят от устройства):

# Пример-скелет (пути, слоты и pin — из документации вашего HSM и HashiCorp)
seal "pkcs11" {
  lib            = "/usr/lib/libCryptoki2.so"
  slot           = "0"
  pin            = "env:VAULT_HSM_PIN" # лучше env/файл с правами root-only, не plain text в репо
  key_label      = "vault-hsm-key"
  hmac_key_label = "vault-hsm-hmac"
}

Best practices:

  • FIPS-совместимый HSM там, где требуется регуляторика;
  • пин-коды и слоты — через secret delivery (Kubernetes Secret с ротацией, TPM, и т.д.), не в Git;
  • тестировать перезапуск Vault и simulated HSM unavailable на стенде;
  • иметь контракт с вендором на поставку ПО под вашу ОС и версию Vault.

FIPS mode

Сборки Vault Enterprise + FIPS 140-2 (и последующие стандарты — по линейке продуктов HashiCorp): отдельные бинарники с ограниченным набором криптоалгоритмов, согласованным с сертификацией.

Практика Зачем
Использовать официальный FIPS-образ/пакет Несертифицированная сборка с «включённым FIPS» на уровне ОС не заменяет продуктовый режим Vault
Проверить совместимость плагинов Сторонние secrets engines могут требовать неразрешённые алгоритмы
Зафиксировать версию в change management Обновления только после проверки матрицы соответствия

Комментарий: режим entitlement + лицензия; для OSS ориентируйтесь на FIPS-совместимую ОС и политики организации, понимая границы без «FIPS Vault binary».

Свод: OSS vs Enterprise (ориентир)

Возможность OSS Enterprise
Логическая изоляция namespaces Нет (отдельные кластеры / строгие policy) Да
Performance / DR replication Нет Да
Расширенные отчёты и часть платформенных фич Ограничено По лицензии

Краткий checklist

# Вопрос
1 Нужен ли один кластер на бизнес-юниты или физическое разделение?
2 RPO/RTO требуют DR secondary или достаточно off-site Raft snapshot?
3 Регуляторика: HSM / FIPS — зафиксированы в архитектурном решении?
4 Runbook и учения на failover и потерю HSM

Дополнительные материалы