20 lines
4.5 KiB
Markdown
20 lines
4.5 KiB
Markdown
# Вопросы: HashiCorp Vault
|
||
|
||
Опираются на кейс: [CASE.md](CASE.md). Источник — [Alfa-Bank.md](../../interview/Alfa-Bank.md).
|
||
|
||
### Как работает Hashicorp Vault: как вкладываются секреты?
|
||
|
||
Секреты хранятся через secrets engine — самый базовый и распространённый вариант KV (key-value): секрет кладётся по конкретному пути (`vault kv put secret/ci/db-credentials username=... password=...`) и читается тем же путём (`vault kv get`). Под капотом Vault шифрует данные перед записью в storage backend (в моей лабе — in-memory dev-режим, в проде обычно Raft или Consul) собственным мастер-ключом, который в продовом режиме получается через unseal-процесс (Shamir's Secret Sharing — несколько частей ключа, кворум которых нужен, чтобы распечатать хранилище после старта). Помимо статичного KV есть и динамические secrets engines (например, для БД) — Vault может сам генерировать короткоживущие учётные данные на лету, но этого я на своей лабе не поднимал, только статичный KV.
|
||
|
||
### Как наполняется файл секрета?
|
||
|
||
Секрет не «файл» в файловой системе в привычном смысле — это запись в хранилище Vault по определённому пути, доступ к которой идёт через CLI (`vault kv put/get`) или HTTP API. Если приложению/пайплайну нужен именно файл (например, `.env` или конфиг с паролем), это обычно результат отдельного шага: агент/раннер запрашивает секрет через API и материализует его во временный файл на своей стороне непосредственно перед использованием, не храня его в репозитории или в постоянном хранилище.
|
||
|
||
### Как идёт синхронизация с CI/CD?
|
||
|
||
CI-раннер аутентифицируется в Vault (в идеале — не статичным root-токеном, а через auth-метод вроде AppRole или через встроенную OIDC/JWT-аутентификацию от самой CI-системы, если она поддерживается), получает короткоживущий токен с ограниченной политикой доступа, читает нужные секреты через API в рамках выполнения job, и токен истекает сам по TTL после использования. Я на своей лабе прогнал часть этой схемы вручную: завёл политику `ci-readonly` с правом только `read` на путь `secret/data/ci/*`, выписал по ней ограниченный токен и убедился, что им можно читать секрет, но нельзя его перезаписать (`vault kv put` тем же токеном отдаёт Permission denied) — сам CI-раннер (GitLab CI/TeamCity) я в эту схему не встраивал, это на уровне понимания паттерна.
|
||
|
||
### Чем это отличается от того, что секрет просто лежит в переменных CI?
|
||
|
||
Секрет в переменных CI-системы статичен: один раз задан — лежит вечно, доступен всем job без разбора, изменения/ротация требуют ручного вмешательства, и нет отдельного лога, кто и когда именно его читал. Vault даёт: точечные политики доступа (кто и к какому пути может обращаться), короткоживущие токены вместо постоянных секретов, аудит-лог обращений, и возможность динамически генерировать секреты вместо хранения статичных значений.
|