Кейс: HashiCorp Vault (dev-режим + интеграция с CI)

Связь с легендой: ../../legend/LEGEND.md — раздел «Домашняя лаборатория / pet-проект». Vault спрашивали в Альфа-Банке («как работает Hashicorp Vault: как вкладываются секреты, синхронизация с CI/CD») — в рабочем стеке компаний из резюме секреты хранятся через ansible-vault (см. ../ansible/QUESTIONS.md), Vault — отдельный честный pet-кейс поверх этого опыта.

Что нужно реально сделать (домашний стенд)

Vault в dev-режиме (single binary, in-memory storage — не для прода, но для понимания механики более чем достаточно), положить секрет через KV-движок, прочитать его через CLI и через HTTP API, завести простую политику доступа, и на уровне паттерна разобрать, как секрет из Vault попадает в CI/CD-пайплайн.

1. Запуск

docker run --cap-add=IPC_LOCK -d --name vault-lab \
  -p 8200:8200 \
  -e 'VAULT_DEV_ROOT_TOKEN_ID=lab-root-token' \
  hashicorp/vault server -dev

Dev-режим сразу распечатан (unsealed), с готовым root-токеном — специально упрощённый режим для локальной практики, в проде Vault разворачивается с реальным storage backend (Consul/Raft) и требует ручного unseal через Shamir's Secret Sharing (несколько ключей, из которых нужен кворум для распечатывания).

2. Положить и прочитать секрет через KV

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='lab-root-token'

vault kv put secret/ci/db-credentials username=labuser password=labpass
vault kv get secret/ci/db-credentials
vault kv get -field=password secret/ci/db-credentials

3. То же самое через HTTP API (то, что реально дёргает CI-раннер)

curl -s -H "X-Vault-Token: lab-root-token" \
  http://127.0.0.1:8200/v1/secret/data/ci/db-credentials | jq .data.data

4. Политика доступа (принцип наименьших привилегий)

# ci-readonly-policy.hcl
path "secret/data/ci/*" {
  capabilities = ["read"]
}

vault policy write ci-readonly ci-readonly-policy.hcl
vault token create -policy="ci-readonly" -ttl=1h

Полученным ограниченным токеном (не root) повторить vault kv get — сработает (есть право read); попробовать vault kv put этим же токеном — должно быть отказано (Permission denied), так как в политике только read. Это ядро модели Vault: не «все или ничего», а точечные политики на конкретные пути.

5. Паттерн интеграции с CI/CD (концептуально, без реального раннера)

Типичная схема: CI-раннер (GitLab CI/TeamCity) на старте job аутентифицируется в Vault не статическим токеном в переменных окружения, а через auth-метод (например, AppRole или JWT/OIDC-аутентификация от самого CI, если поддерживается) — получает короткоживущий токен с ограниченной политикой → читает нужные секреты через API → использует их в рамках job → токен истекает сам по TTL. Ключевое отличие от простого хранения секрета в CI-переменных: секрет не лежит статично в конфигурации пайплайна, доступ временный и аудируемый (Vault логирует каждое обращение).

Что это даёт в разговоре с интервьюером

Практическое понимание KV secrets engine — как секрет реально «вкладывается» и читается, а не абстрактно.
Понимание политик доступа Vault (HCL, path-based capabilities) на реальном примере — не просто «там есть права», а конкретный сценарий read-only токена.
Понимание разницы между dev-режимом (для лабы) и продовым Vault (unseal, storage backend, HA) — честная граница того, что реально прогнано.
Осмысленное представление о паттерне интеграции с CI/CD через short-lived токены, а не статичные секреты в переменных.

Как это ложится в легенду

Vault — pet-кейс, не приписанный к опыту в компаниях. В резюме и легенде реальный опыт хранения секретов зафиксирован через ansible-vault в АО ТНИИС; Vault добавляется отдельно как самостоятельно проработанная технология в навыках, без утверждения, что она использовалась на рабочем месте.

5.8 KiB Raw Blame History Unescape Escape