68 lines
5.8 KiB
Markdown
68 lines
5.8 KiB
Markdown
# Кейс: HashiCorp Vault (dev-режим + интеграция с CI)
|
||
|
||
Связь с легендой: [../../legend/LEGEND.md](../../legend/LEGEND.md) — раздел «Домашняя лаборатория / pet-проект». Vault спрашивали в Альфа-Банке («как работает Hashicorp Vault: как вкладываются секреты, синхронизация с CI/CD») — в рабочем стеке компаний из резюме секреты хранятся через `ansible-vault` (см. [../ansible/QUESTIONS.md](../ansible/QUESTIONS.md)), Vault — отдельный честный pet-кейс поверх этого опыта.
|
||
|
||
## Что нужно реально сделать (домашний стенд)
|
||
|
||
Vault в dev-режиме (single binary, in-memory storage — не для прода, но для понимания механики более чем достаточно), положить секрет через KV-движок, прочитать его через CLI и через HTTP API, завести простую политику доступа, и на уровне паттерна разобрать, как секрет из Vault попадает в CI/CD-пайплайн.
|
||
|
||
### 1. Запуск
|
||
|
||
```bash
|
||
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
|
||
|
||
```bash
|
||
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-раннер)
|
||
|
||
```bash
|
||
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. Политика доступа (принцип наименьших привилегий)
|
||
|
||
```hcl
|
||
# ci-readonly-policy.hcl
|
||
path "secret/data/ci/*" {
|
||
capabilities = ["read"]
|
||
}
|
||
```
|
||
|
||
```bash
|
||
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 добавляется отдельно как самостоятельно проработанная технология в навыках, без утверждения, что она использовалась на рабочем месте.
|