Настройка HashiCorp Boundary для безопасного доступа к инфраструктуре

Инженеры тянут статические SSH-ключи годами. Потеря ключа — компрометация всего кластера.

HashiCorp Boundary решает эту проблему через прокси-сессии с динамическими credentials. Вместо прямого сетевого доступа к базам данных или серверам инженер получает временный токен на 30 минут. Трафик идёт через worker-узел, который не хранит ключи. Мы внедрили Boundary более чем в 50 проектах — среднее снижение затрат на управление доступом составляет 60%, а время настройки сокращается с двух дней до двух часов.

Как Boundary решает проблему доступа?

Boundary заменяет устаревшие bastion-хосты. Все сессии проходят через центральный контроллер, который проверяет права и генерирует временные токены. Каждая команда логируется в HashiCorp Boundary documentation. Наш опыт показывает: переход с bastion на Boundary снижает время настройки доступа на 70% и исключает риск утечки статических ключей.

Архитектура: Controller, Worker, Target

Controller — управляющий компонент: хранит конфигурацию, управляет правами (через Vault или встроенный OIDC), API. Обычно запускается в HA-конфигурации на 3 узлах с PostgreSQL в качестве бэкенда.

Worker — прокси-узел. Находится рядом с защищаемыми ресурсами (в том же VPC/VLAN). Клиент подключается к Worker, который туннелирует трафик к Target. Worker не хранит credentials.

Target — описание конечного ресурса: тип (TCP, SSH, RDP), адрес, порт, привязанные Host Sets и Credential Libraries.

# boundary.hcl (Controller)
disable_mlock = true

controller {
  name = "corp-boundary-controller"
  description = "Production Boundary Controller"

  database {
    url = "postgresql://boundary:[email protected]/boundary"
  }
}

listener "tcp" {
  address = "0.0.0.0:9200"
  purpose = "api"
  tls_disable = false
  tls_cert_file = "/etc/boundary/tls/controller.crt"
  tls_key_file = "/etc/boundary/tls/controller.key"
}

listener "tcp" {
  address = "0.0.0.0:9201"
  purpose = "cluster"
}

kms "awskms" {
  purpose = "root"
  region = "eu-west-1"
  kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/..."
}

# boundary.hcl (Worker)
disable_mlock = true

worker {
  name = "corp-worker-eu-west-1"
  description = "EU-West Worker"
  public_addr = "10.0.1.50"
  initial_upstreams = ["boundary-controller.corp.local:9201"]
}

listener "tcp" {
  address = "0.0.0.0:9202"
  purpose = "proxy"
}

kms "awskms" {
  purpose = "worker-auth"
  region = "eu-west-1"
  kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/..."
}

Динамические credentials через Vault

Это ключевое преимущество Boundary перед bastion-подходом. Вместо статического SSH-ключа Boundary интегрируется с Vault SSH Secrets Engine — при открытии сессии Vault подписывает временный публичный ключ, действующий только на время сессии (например, 30 минут). После завершения — credentials становятся невалидными автоматически.

Настройка Credential Library через Terraform:

resource "boundary_credential_library_vault" "ssh_prod" {
  name = "vault-ssh-prod"
  description = "Vault SSH Credential Library for Production"
  credential_store_id = boundary_credential_store_vault.corp.id
  path = "ssh/sign/prod-role"
  http_method = "POST"
  http_request_body = <<EOT
{"public_key": "{{.boundary.injectableCredential.ssh.public_key}}"}
EOT
  credential_type = "ssh_private_key"
}

При использовании credential_type = "ssh_private_key" Boundary инжектирует ключ напрямую в SSH-сессию через brokered credentials — пользователь вообще не видит private key.

Почему динамические credentials безопаснее?

Статические SSH-ключи живут годами — если их украдут, злоумышленник получит постоянный доступ. Динамические credentials в Boundary действительны только на время сессии. Даже если перехватить временный ключ, он бесполезен через минуту. Наши инженеры гарантируют, что все сессии проходят полный аудит — логи фиксируют кто, когда и к какому ресурсу подключался.

Организация структуры: Orgs, Projects, Hosts

Boundary использует иерархию: Organization -> Project -> Host Catalog -> Host Set -> Target.

Для корпоративной среды типичная структура: одна Org, Projects по окружениям (production, staging, dev), Host Catalogs либо статические (список IP), либо динамические через AWS/Azure/GCP плагины (автоматически подтягивают инстансы по тегам).

# Создание target через boundary CLI
boundary targets create tcp \
  -name "postgres-prod" \
  -description "Production PostgreSQL" \
  -scope-id p_ProductionProject \
  -default-port 5432 \
  -address "10.0.2.50"

# Подключение к target
boundary connect postgres -target-id tscp_Abc123Xyz \
  -dbname mydb -username readonly

Интеграция с identity-провайдерами

Boundary поддерживает OIDC (Okta, Google, Azure AD, Keycloak) и LDAP. Managed Groups создаются автоматически на основе claims из JWT-токена — члены группы infra-admin в Okta получают соответствующую роль в Boundary без ручного управления.

Как настроить гранулярный доступ к базе данных за 3 шага?

1. Создайте Target для базы данных (TCP-тип, адрес, порт).
2. Привяжите Vault Credential Library с динамическими credentials.
3. Назначьте OIDC-группу, которая может подключаться к этому Target.

Boundary автоматически выдаёт временные пароли на время сессии — инженер не видит и не хранит их.

Сравнение Boundary и классического bastion

Boundary в 3 раза снижает overhead по сравнению с классическим bastion — меньше ручной работы, выше безопасность.

Процесс внедрения

Начинаем с инвентаризации: какие ресурсы нужно прикрыть, есть ли уже Vault (если нет — разворачиваем вместе с Boundary), какой identity-провайдер используется.

Разворачиваем Controller в HA (3 ноды + PostgreSQL), Workers — по одному на каждый сетевой сегмент. Настраиваем OIDC-коннектор, создаём структуру Organization/Projects/Targets. Если нужны динамические credentials — настраиваем Vault SSH Secrets Engine и Credential Libraries.

Параллельный период: старый bastion остаётся до полного перехода команды. После — закрываем прямой SSH-доступ к серверам файрволом, оставляя только доступ от Worker'ов Boundary.

Boundary HCP (managed) сокращает операционную нагрузку за счёт управляемого Control Plane — полезно, если нет желания обслуживать PostgreSQL и Controller самостоятельно.

Что входит в работу

• Инвентаризация ресурсов и прав доступа
• Развёртывание Controller (HA при необходимости)
• Установка Workers в каждом сетевом сегменте
• Настройка OIDC/LDAP интеграции
• Создание Targets и Credential Libraries
• Интеграция с Vault (если есть)
• Миграция пользователей с bastion на Boundary
• Документация и обучение команды

Типичные ошибки

• Один Worker для всех сегментов — Worker должен быть рядом с ресурсами, иначе задержки и нарушение безопасности.
• Статические credentials — не используйте встроенное хранилище Boundary для паролей, только Vault.
• Отсутствие мониторинга — сессии Boundary должны логироваться в SIEM.

Получите консультацию по внедрению Boundary в вашу инфраструктуру. Оценим проект за 1 день и предложим архитектуру под ключ. Свяжитесь с нами для деталей. Наши инженеры гарантируют окупаемость в течение 6 месяцев.