Налаштування 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 місяців.