Kubernetes, LDAP и OIDC

Как поды логинятся «своим» токеном, а сотрудники — через корпоративный логин или SSO.

Kubernetes auth позволяет поду логиниться в Vault своим ServiceAccount-токеном; LDAP/OIDC дают людям вход по корпоративным учёткам и SSO.

AppRole универсален, но в типичных средах есть способы проще. В Kubernetes у каждого пода уже есть удостоверение — ServiceAccount-токен. У людей уже есть аккаунт в LDAP/AD или SSO-провайдере. Vault умеет принимать их напрямую.

Kubernetes auth для подов

Идея: под предъявляет свой JWT от ServiceAccount, Vault просит сам Kubernetes подтвердить его подлинность (TokenReview) и, если ОК, выдаёт токен с политиками роли.

vault auth enable kubernetes

vault write auth/kubernetes/config \
  kubernetes_host="https://kubernetes.default.svc"

vault write auth/kubernetes/role/myapp \
  bound_service_account_names=myapp-sa \
  bound_service_account_namespaces=prod \
  token_policies=myapp-read \
  ttl=1h

Логин пода: он шлёт имя роли и свой ServiceAccount-токен.

vault write auth/kubernetes/login \
  role=myapp \
  jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

Параметры bound_service_account_* жёстко ограничивают, какие SA и namespace допускаются — под из чужого namespace роль не получит.

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

Vault не доверяет JWT на слово. Получив токен пода, он вызывает Kubernetes API (TokenReview), и уже сам кластер подтверждает: «да, этот токен принадлежит SA myapp-sa в namespace prod, и он активен». Так доказательство личности делегируется доверенному источнику — самому Kubernetes.

LDAP для людей

LDAP связывает Vault с корпоративным каталогом (AD/OpenLDAP). Человек входит логином и паролем, а группы каталога маппятся на политики:

vault auth enable ldap

vault write auth/ldap/config \
  url="ldaps://ad.corp.local" \
  userdn="ou=Users,dc=corp,dc=local" \
  groupdn="ou=Groups,dc=corp,dc=local"

# группа devops -> политика admin
vault write auth/ldap/groups/devops policies=admin

vault login -method=ldap username=ivan

OIDC: вход через SSO

OIDC подключает Vault к провайдеру (Okta, Keycloak, Google). Человек логинится в браузере через привычный SSO, а Vault получает подтверждённую личность и маппит claims на политики. Это даёт единый вход, MFA на стороне провайдера и удобный аудит по людям.

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

• Не ограничить bound_service_account_namespaces — любой под кластера получит доступ.
• Использовать ldap:// без TLS — пароли пойдут по сети открыто, нужен ldaps://.
• Маппить слишком широкие группы на admin-политику — нарушение наименьших привилегий.

Итог

• Kubernetes auth логинит поды их SA-токеном; подлинность подтверждает сам кластер.
• LDAP даёт людям вход по корпоративному логину, маппя группы на политики.
• OIDC подключает SSO с MFA и аудитом по личности; выбор метода зависит от среды.