Токены для доступа к API Kubernetes
До версии 1.22 в Kubernetes автоматически создавались токены для доступа к API Kubernetes. Этот механизм был основан на создании секретов с токенами, которые затем можно было монтировать в работающий pod. В более новых версиях доступ к API получают непосредственно с помощью API TokenRequest и монтируют токен в pod. Токены, полученные таким образом, имеют ограниченный срок действия и автоматически аннулируются при удалении пода, в который они вмонтированы.
При необходимости вы всё ещё можете вручную создавать секрет с токеном для учётной записи сервиса, например если вам нужен токен, который никогда не истекает.
Подробнее о настройке сервисного аккаунта — в документации Configure Service Accounts for Pods | Kubernetes.
Инструкция, как найти токен в работающем поде, на примере CoreDNS
- Найдите имя пода CoreDNS:
kubectl get pods -n kube-system - Посмотрите, по какому пути смонтирован секрет:
kubectl get pod/coredns-787d4945fb-8gj5c -n kube-system -o yaml - Запустите эфемерный контейнер, так как в CoreDNS нет shell и иначе доступ к нему не получить:
kubectl debug -it coredns-787d4945fb-8gj5c --image=busybox:1.28 --target=coredns -n kube-system - Посмотрите содержимое каталога:
ls /proc/1/root/var/run/secrets/kubernetes.io/serviceaccount/
В нём будет три файла: ca.crt, namespace, token. Каждый из них можно прочитать. Чтобы узнать, какой токен использует CoreDNS, необходимо выполнить cat файла token:
cat /proc/1/root/var/run/secrets/kubernetes.io/serviceaccount/token
Токен указан в открытом виде, его не нужно расшифровывать. Также обратите внимание, что токен не содержит переноса на новую строку.
Этот токен можно использовать для обращения к API Kubernetes.
Аутентификация в Kubernetes: Кто стучится в API?
Когда вы отправляете запрос к API-серверу, Kubernetes должен ответить на вопрос: «Кто вы?». Важно понимать, что в Kubernetes нет объекта «User» (пользователь) в базе данных etcd. Пользователи управляются внешними механизмами, а внутри кластера существуют только Service Accounts.
Жизненный цикл запроса
Аутентификация — это самый первый этап обработки запроса API-сервером.
- Authentication (Аутентификация): Проверка личности (токен, сертификат).
- Authorization (Авторизация): Проверка прав (можно ли вам делать то, что вы просите).
- Admission Control: Финальная проверка и мутация объекта.
Если аутентификация не удалась, сервер возвращает ошибку HTTP 401 (Unauthorized).
Два типа субъектов
1. Нормальные пользователи (Normal Users)
Это живые люди (администраторы, разработчики).
- Где хранятся: Вне Kubernetes (LDAP, Google Accounts, файлы с паролями).
- Как проверяются: Через клиентские сертификаты или внешние IDP.
2. Сервисные аккаунты (Service Accounts)
Это «пользователи» для приложений и процессов, запущенных внутри кластера (например, для подов).
- Где хранятся: Как полноценные объекты в API Kubernetes.
- Как проверяются: Через JWT-токены, которые автоматически монтируются в поды.
Основные механизмы аутентификации
1. Клиентские сертификаты (X509)
Самый надежный способ. Пользователь предъявляет сертификат, подписанный корневым CA кластера. API-сервер проверяет подпись и извлекает имя пользователя из поля Common Name (CN).
2. Статический файл токенов (Static Token File)
Простой способ, где токены прописаны в CSV-файле на мастере.
Минус: Требует перезагрузки API-сервера для изменения списка пользователей. Не рекомендуется для продакшена.
3. Bearer-токены (Service Account Tokens)
JWT-токены, которые создаются автоматически для каждого ServiceAccount. Под монтирует этот токен и использует его для запросов к API.
# Пример того, как под использует ServiceAccount
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
serviceAccountName: build-robot # Имя аккаунта
4. OpenID Connect (OIDC) Токены
Позволяет подключить внешних провайдеров (Google, GitHub, Okta). Вы логинитесь в стороннем сервисе, получаете токен, и Kubernetes доверяет этому сервису.
5. Аутентифицирующий прокси (Authenticating Proxy)
API-сервер доверяет заголовкам (например, X-Remote-User), которые проставляет прокси-сервер, стоящий перед ним.
Проверка текущего пользователя
Вы всегда можете проверить, под каким именем и с какими правами вы сейчас находитесь в кластере, с помощью команды:
kubectl auth can-i --list
Или узнать свой текущий контекст из конфига:
kubectl config view --minify
Итог
| Метод | Субъект | Рекомендуемое использование |
| X509 Certificates | Люди / Админы | Прямой доступ к кластеру, настройка узлов. |
| Service Account Tokens | Поды / Роботы | Внутренняя автоматизация кластера. |
| OIDC (OAuth2) | Люди / Команды | Корпоративный доступ (SSO). |
| Webhook Token | Любой | Внешние системы проверки (например, Guard). |
Важно: Аутентификация только подтверждает, что вы — это вы. Она не дает никаких прав. После успешного входа в игру вступает RBAC (Role-Based Access Control), который определяет, к каким ресурсам у вас есть доступ.