Auth-методы и принцип логина

Общая модель: предъявляешь удостоверение подходящим методом — получаешь токен с правами.

Auth-метод (метод аутентификации) — подключаемый способ доказать Vault свою личность; в случае успеха Vault выдаёт токен, к которому привязаны политики.

Vault не хранит «пользователей» в привычном смысле. Вместо этого он принимает разные доказательства личности: пароль LDAP, JWT от Kubernetes, секретный идентификатор AppRole. Любой успешный логин заканчивается одинаково — выдачей токена.

Логин в обмен на токен

Принцип универсален: клиент логинится одним из методов, Vault проверяет доказательство и возвращает токен. Дальше все запросы клиент шлёт уже с этим токеном.

[ Клиент ]
   | (1) логин: метод + доказательство
   v
[ Auth-метод ] -- проверяет --> [ Identity ]
   | (2) выдаёт токен + политики
   v
[ Клиент ] -- (3) запросы с токеном --> [ секреты ]

Методы для людей и для машин

Ключевое разделение: люди и приложения логинятся по-разному.

Метод	Для кого
token	базовый, прямая выдача токенов
userpass / LDAP / OIDC	люди (вход по паролю/SSO)
AppRole	приложения и CI
Kubernetes	поды в кластере
AWS / GCP / Azure	облачные ВМ по их identity

Монтирование метода

Как и движки секретов, auth-методы монтируются по путям под auth/:

vault auth enable approle
vault auth enable kubernetes
vault auth enable -path=corp-ldap ldap

vault auth list

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

Логин — это запрос на путь auth/<метод>/login. Метод проверяет доказательство и говорит ядру Vault: «это сущность X, выдай ей токен с политиками Y и TTL Z». Ядро создаёт токен и возвращает его. Сам токен — это и есть «ключ доступа»: он живёт ограниченное время и несёт привязанные политики. Таким образом, аутентификация (кто ты) и авторизация (что тебе можно) разведены: метод устанавливает личность, политики решают доступ.

{
  "auth": {
    "client_token": "hvs.CAES...",
    "policies": ["default", "myapp-read"],
    "lease_duration": 3600,
    "renewable": true
  }
}

Почему это удобно

Разделение методов и токенов означает, что секреты и политики не зависят от способа входа. Приложение может перейти с AppRole на Kubernetes-auth, а политики останутся теми же — меняется лишь «дверь», через которую получают тот же токен.

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

Использовать токены напрямую для приложений вместо AppRole/k8s — токен надо где-то хранить, возвращается проблема secret zero.
Логинить людей через AppRole — для людей есть LDAP/OIDC с привычным входом и аудитом по личности.
Забыть привязать политики к роли метода — токен получит только default и ничего не прочитает.

Итог

Auth-методы — это разные «двери», но все они ведут к одному: выдаче токена.
Люди входят через LDAP/OIDC/userpass, приложения — через AppRole/Kubernetes/облачные методы.
Метод устанавливает личность, а доступ определяют привязанные к токену политики.