Политики на HCL и capabilities

Язык, которым в Vault описывают «кому к каким путям и что именно можно».

Политика (policy) — документ на HCL, перечисляющий пути и разрешённые на них capabilities (операции); политики привязываются к токенам и определяют авторизацию.

Аутентификация решает, кто вы. Политика решает, что вам можно. Поскольку в Vault всё — пути, политика — это просто список путей с набором разрешённых операций.

Структура политики

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

path "secret/metadata/myapp/*" {
  capabilities = ["list"]
}

Каждый блок path описывает один путь (можно с подстановкой) и список capabilities. Эта политика разрешает читать секреты приложения и перечислять их метаданные — и ничего больше.

Capabilities

deny приоритетнее всего

Важнейшее правило: deny побеждает любые разрешения. Если хотя бы одна политика токена запрещает путь, доступа не будет, даже если другая его разрешает. Это позволяет надёжно «вырезать» опасные пути.

path "secret/data/*" {
  capabilities = ["read"]
}

# но к prod-секретам -- нельзя, несмотря на правило выше
path "secret/data/prod/*" {
  capabilities = ["deny"]
}

Применение политики

vault policy write myapp-read myapp-read.hcl
vault policy list
vault policy read myapp-read

Дальше политику привязывают к роли auth-метода (например, token_policies=myapp-read), и все выданные через неё токены получают эти права.

Как работает под капотом

При каждом запросе Vault собирает все политики токена, ищет наиболее специфичное правило для запрашиваемого пути и проверяет, входит ли нужная capability в разрешённые. Сопоставление путей идёт по приоритету точности: точное совпадение важнее шаблона с *. Glob * работает только в конце пути; для подстановки в середине есть параметризованные шаблоны + и сегменты.

Политика default и root

Каждому токену (кроме явно очищенных) автоматически прикрепляется политика default — она даёт минимум: посмотреть свой токен, разлогиниться. Особая псевдо-политика root снимает все ограничения; её получают только root-токены, и в проде их быть не должно.

Частые ошибки

• Забыть data/ в пути KV v2 — secret/myapp/* не даст доступа к secret/data/myapp/*.
• Путать read и list — чтобы видеть имена ключей, нужен list, отдельно от read.
• Слишком широкий glob вроде secret/* с write — это почти root по секретам.
• Думать, что allow перебьёт deny — нет, deny всегда побеждает.

Итог

• Политика — HCL-список путей с разрешёнными capabilities (create/read/update/delete/list/deny).
• deny приоритетнее любых разрешений и надёжно закрывает путь.
• Для KV v2 в путях нужен data/; точное правило важнее шаблона с *.