# Token reviewer для метода auth/kubernetes.
#
# Vault живёт ВНЕ кластера, поэтому не может воспользоваться ни своим
# ServiceAccount-токеном, ни CA из /var/run/secrets. Чтобы он мог проверять
# токены подов, ему выдаётся отдельный ServiceAccount с правом обращаться к
# TokenReview API — ClusterRole `system:auth-delegator` (встроенная).
#
# Схема целиком: под с аннотациями vault.hashicorp.com/* → injector добавляет
# init-контейнер vault-agent → агент логинится в Vault токеном ServiceAccount'а
# пода → Vault валидирует этот токен через TokenReview от имени vault-auth →
# при успехе отдаёт секреты, агент кладёт их файлами в /vault/secrets/.
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: vault-auth
  namespace: vault
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: vault-auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: vault-auth
    namespace: vault
---
# Долгоживущий токен ServiceAccount'а. С k8s 1.24 секрет-токен больше не
# создаётся автоматически при создании SA, а `kubectl create token` выдаёт
# токен с TTL — он протух бы, и Vault перестал бы валидировать логины.
# Секрет типа service-account-token с этой аннотацией заполняет
# token-controller: в него попадают и `token`, и `ca.crt` кластера.
apiVersion: v1
kind: Secret
metadata:
  name: vault-auth-token
  namespace: vault
  annotations:
    kubernetes.io/service-account.name: vault-auth
type: kubernetes.io/service-account-token