Управление доступом в микросервисной архитектуре: JWT, API-шлюзы и сервис-меш

Надежная IAM-схема для микросервисов строится из четырех уровней: IdP через OpenID Connect и OAuth 2.0 аутентифицирует субъект и выдает короткоживущий JWT, API Gateway проверяет входящий запрос, сервис принимает решение о доступе к конкретному ресурсу, сервис-меш подтверждает identity workload и шифрует трафик через mTLS.

JWT, API-шлюз и service mesh решают разные задачи. JWT переносит подтвержденный контекст пользователя или API-клиента. Gateway защищает внешний HTTP или gRPC-периметр. Istio или Linkerd ограничивает доверие между workload внутри Kubernetes. Пользовательский token не должен быть единственным барьером для вызовов между сервисами.

Клиент -> IdP/OIDC -> access token JWT -> API Gateway
                                      |
                                      v
                              сервис-меш, mTLS
                                      |
                                      v
                    микросервисы -> audit log и метрики

Для межсервисных вызовов используйте отдельную workload identity, связанную с Kubernetes ServiceAccount и сертификатом mesh. Пользовательский JWT передавайте только там, где сервису нужен контекст пользователя для проверки tenant_id, владельца ресурса, scope или бизнес-прав.

Рабочая схема контроля доступа в распределенной системе

Какие угрозы должна закрывать система IAM

Защита только ingress не закрывает внутренние вызовы. Pod с сетевым доступом к Service способен обратиться к API напрямую, если нет сетовых ограничений, mTLS и правил авторизации workload. С другой стороны, mTLS подтверждает источник запроса на уровне workload, но не отвечает на вопрос, разрешено ли пользователю изменить конкретный заказ или прочитать документ другого арендатора.

Границы ответственности: IdP, API-шлюз, сервис, сервис-меш

Полезное правило: gateway отвечает на вопрос «можно ли допустить запрос к маршруту», а сервис отвечает на вопрос «разрешено ли этому субъекту действие над этим ресурсом». Mesh отвечает на вопрос «какой workload установил соединение и разрешен ли ему такой вызов».

Модель идентичности для пользователей, API-клиентов и микросервисов

В одном кластере обычно работают три вида субъектов: интерактивные пользователи, machine-to-machine API-клиенты и Kubernetes workload. Для них нужны отдельные client registration, grant type, scopes и правила отзыва. Универсальный токен с широкими правами быстро превращается в источник избыточного доступа.

Пользовательские и клиентские токены OAuth 2.0

Для браузерных и нативных клиентов используйте Authorization Code с PKCE. Этот поток не передает пароль пользователя приложению и снижает риск перехвата authorization code. Для фоновой интеграции между двумя зарегистрированными системами используйте Client Credentials и отдельный client_id для каждой интеграции.

Не передавайте пароль пользователя, refresh token или long-lived API key между микросервисами. Сервис, получивший пользовательский access token, должен либо передать его далее только по защищенному каналу при наличии оправданной бизнес-потребности, либо запросить отдельный сервисный credential. У токена API-клиента должен быть subject, который однозначно указывает на клиент, а scopes должны описывать минимальный набор операций.

Идентичность workload в Kubernetes

Workload identity связывает pod с Kubernetes ServiceAccount, namespace и сертификатом mTLS. Istio и Linkerd используют эту идентичность для подтверждения стороны соединения. Политика может разрешить вызов только от service account payments-api из namespace billing, а запрос от pod из другого namespace отклонить до обработки приложением.

ServiceAccount не заменяет пользовательские права. Сервис orders может иметь право вызвать inventory, но пользователь внутри исходного запроса все еще обязан иметь scope на создание заказа и доступ к своему tenant. Разделение идентичностей снижает риск, при котором техническое право сервиса ошибочно дает пользователю расширенный доступ.

JWT токены: выпуск, состав claims и валидация

JWT - подписанный переносимый credential. Его payload обычно кодируется Base64URL, а не шифруется. Любой участник с доступом к токену может прочитать claims, поэтому не помещайте туда пароли, API-ключи, refresh token, внутренние секреты, полные персональные сведения и часто меняющиеся права.

Для распределенной проверки удобна асимметричная подпись: IdP хранит закрытый ключ, а gateway и сервисы получают публичные ключи через JWK или JWKS. Проверяющие компоненты не должны получать ключ подписи. Минимальный набор claims включает subject, issuer, audience, время жизни и идентификатор ключа.

Какие claims проверять при каждом запросе

Допустимый clock skew должен быть малым и одинаковым на gateway и сервисах. Настройте синхронизацию времени на узлах кластера. Отсутствие критичного claim, например aud или exp, трактуйте как ошибку валидации, а не как необязательный случай.

1. Извлечь Bearer token из Authorization.
2. Прочитать header и найти kid.
3. Найти kid только в кеше доверенного JWKS конкретного issuer.
4. Проверить подпись только разрешенным алгоритмом.
5. Проверить iss, aud, exp, nbf и обязательные claims.
6. Проверить scope для маршрута или операции.
7. Передать проверенный контекст в авторизацию ресурса.

Что можно и нельзя помещать в JWT

Добавляйте в JWT стабильный sub, ограниченный набор scopes, tenant context при необходимости и атрибуты, без которых нельзя принять решение. Роль допустима как грубый признак доступа, но сервис не должен считать ее единственным доказательством права на объект. Для документа, заказа или учетной записи обычно требуется проверить владельца, tenant_id, состояние объекта или другие атрибуты.

Не включайте в access token адрес, номер телефона, платежные реквизиты, пароль, API key, секреты интеграций и полный профиль пользователя. Часто меняющиеся права тоже лучше не переносить в длинноживущий JWT: после смены роли старый token продолжит нести устаревший набор claims до истечения TTL.

Типовые ошибки при проверке подписи JWT

• Не принимайте алгоритм none.
• Не выбирайте алгоритм автоматически по значению header. Сервис хранит разрешенный список алгоритмов в конфигурации.
• Не используйте один и тот же ключ как HMAC-секрет и как RSA или EC публичный ключ.
• Не загружайте JWKS по адресу, полученному из token header или payload.
• Не принимайте неизвестный kid до обновления доверенного JWKS.
• Не отключайте проверку audience ради совместимости с несколькими API.

Кешируйте JWKS с контролируемым сроком обновления. При неизвестном kid можно однократно инициировать обновление key set, затем повторить проверку. Если ключ не найден, верните 401 и зафиксируйте событие unknown_kid. Постоянные ошибки такого типа после ротации указывают на рассинхронизацию IdP и проверяющих компонентов.

API-шлюз: аутентификация и защита внешнего периметра

API Gateway принимает внешний HTTP и gRPC-трафик, завершает TLS при выбранной модели, проверяет Bearer token, применяет rate limiting, ограничивает размер запроса, задает CORS и направляет запрос в нужный сервис. Эти проверки должны быть единообразными для всех публичных маршрутов.

Разбор диагностических сценариев для 401, 403, срока JWT, scopes и заголовка Authorization собран в статье об ошибках аутентификации при обращении к API. Для сложной маршрутизации, канареечных релизов и JWT-политик полезен материал о настройке маршрутизации в Kong и Apache APISIX.

Какие проверки выполнять на API-шлюзе

• Проверка TLS и допустимых версий протокола.
• Проверка формата Authorization: Bearer <token>.
• JWT валидация: подпись, iss, aud, exp, nbf и обязательные claims.
• Проверка route-scopes, например права на запись в API до передачи запроса сервису.
• Ограничение размера body, числа заголовков, времени ожидания и частоты запросов.
• Разделение публичных, анонимных, административных и партнерских маршрутов.

Возвращайте 401, когда credential отсутствует, просрочен или не проходит проверку. Возвращайте 403, когда token валиден, но scope или политика не разрешает действие. Ответ не должен раскрывать имя внутреннего сервиса, структуру mesh, список разрешенных ролей или подробности ключа подписи.

Как передавать контекст пользователя во внутренние сервисы

Предпочтительный вариант: gateway передает исходный подписанный access token по защищенному каналу, а сервис повторно валидирует token там, где принимает авторизационное решение. Такой подход сохраняет проверяемый subject, audience и claims без доверия к текстовым заголовкам.

Gateway может добавлять заголовки с identity, например subject или tenant_id, для технического удобства. Сервис принимает их только при одновременном выполнении трех условий: прямой доступ клиента к сервису закрыт, источник подтвержден gateway или sidecar через mTLS, заголовки от внешнего клиента удаляются или перезаписываются на ingress. Заголовок X-User-ID, пришедший из интернета, не может служить доказательством личности.

Что не следует переносить в API-шлюз

Не переносите в gateway правила владения документом, связь заказа с tenant, допустимое состояние бизнес-объекта и другие проверки, которым нужны данные сервиса. Gateway не владеет предметной моделью и быстро потеряет согласованность с сервисами. Оставьте такие решения владельцу ресурса или вынесите повторяющиеся правила в policy engine.

Авторизация в сервисах: scopes, роли и доступ к ресурсам

Успешная аутентификация подтверждает субъект. Авторизация проверяет разрешение на конкретное действие. Валидный JWT с scope на чтение каталога не дает право изменить чужой заказ, просмотреть данные другого tenant или вызвать административный маршрут.

RBAC, scopes и ABAC: что выбрать для микросервисов

Scopes хорошо ограничивают поверхность API. RBAC упрощает стабильные права. ABAC нужен, когда решение зависит от атрибутов запроса и ресурса. В мультитенантных системах роль без проверки tenant_id оставляет риск чтения или изменения чужих объектов.

Проверка tenant-границ и владения ресурсом

Не берите tenant_id из query parameter, body или path как источник доверия. Сервис получает tenant context из валидированного JWT либо из server-side контекста, построенного доверенным компонентом. Параметр запроса может использоваться для поиска объекта, но найденный объект должен пройти проверку границы арендатора.

Разрешить изменение заказа, если:
1. token содержит scope orders.write;
2. order.tenant_id совпадает с token.tenant_id;
3. subject владеет заказом или имеет разрешенную роль;
4. текущее состояние заказа допускает изменение.

Проверку выполняйте до возврата данных и до изменения ресурса. Проверка после частичной записи приводит к сложным сценариям отката и аудита. Для списков фильтруйте выборку по tenant_id на уровне запроса к хранилищу, а не только после получения объектов в памяти.

Когда нужен внешний policy engine

Внешний policy engine оправдан, когда несколько сервисов используют одинаковые правила, политики требуют централизованного управления или команде нужен аудит решений. Policy decision point принимает решение, policy enforcement point в сервисе применяет его к запросу. Enforcement point остается рядом с ресурсом и не должен превращаться в пассивный прокси.

До подключения policy engine определите поведение при его недоступности. Для операций с деньгами, персональными сведениями и административными правами используйте deny by default. Для второстепенного чтения можно выбрать ограниченный деградированный режим, но он должен быть документирован и протестирован.

Istio авторизация и Linkerd: защита межсервисного трафика

Service mesh автоматизирует mTLS между подключенными workload и делает идентичность источника частью сетовой политики. Это закрывает plaintext-вызовы и уменьшает доверие между namespace. Общее устройство mesh, его границы с Ingress, API Gateway и NetworkPolicy разобраны в статье о service mesh в Kubernetes.

Включение strict mTLS и принцип deny by default

Переход к strict mTLS проводите поэтапно. Сначала составьте карту зависимостей, проверяйте readiness и liveness probes, cron jobs, ingress, egress, webhook и внешние системы. Затем включите режим совместимости или наблюдения для ограниченного набора namespace, устраните plaintext-трафик и только после этого включайте strict mTLS.

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: STRICT

После strict mTLS добавьте явные allow-политики. Наличие allow-политики для workload означает запрет всех запросов, которые не совпали с ее правилами. Проверяйте namespace, ServiceAccount, порт и направление вызова. Пошаговый сценарий миграции, диагностики и отката описан в материале о включении mTLS без сбоев трафика.

Istio RequestAuthentication и AuthorizationPolicy для JWT

Istio RequestAuthentication извлекает и проверяет JWT по issuer и доверенному JWKS. Сама по себе эта политика не требует token: запрос без JWT может пройти дальше. Для защищенного маршрута добавьте AuthorizationPolicy, которая разрешает только проверенный request principal или требует нужный claim.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: orders-api
  namespace: orders
spec:
  selector:
    matchLabels:
      app: orders-api
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["idp-prod/*"]
    to:
    - operation:
        methods: ["POST"]
        paths: ["/api/orders"]
    when:
    - key: request.auth.claims[scope]
      values: ["orders.write"]

Проверяйте фактический формат scope в token. Некоторые IdP передают scope строкой через пробел, другие используют массив или отдельные claims. Политика должна совпадать с реальным форматом claims. Для анонимных health endpoint создайте узкое отдельное правило, а не расширяйте доступ ко всему сервису.

Особенности Linkerd при работе с JWT

Linkerd подтверждает identity meshed workload, шифрует соединения mTLS и дает сетовые средства контроля трафика. JWT-аутентификацию пользователей, проверку audience и scopes выполняйте в API Gateway, приложении или специализированном прокси. Linkerd не заменяет IdP и не знает бизнес-прав пользователя без отдельного слоя проверки.

При выборе между Istio и Linkerd оценивайте нужные L7-политики, операционную сложность, зрелость текущего Kubernetes-стека и требования к наблюдаемости. Независимо от выбора, политика доступа должна проверять identity workload и закрывать прямые неразрешенные вызовы.

Время жизни access token, refresh token и ротация ключей

Срок access token выбирайте по риску операции, типу клиента и доступности повторной аутентификации. Короткий TTL ограничивает ущерб при утечке, но повышает частоту обновления сессии. Длительный TTL снижает нагрузку на IdP, но увеличивает период, когда украденный credential пригоден для использования.

Выбор срока жизни токенов по сценарию доступа

Не выбирайте TTL по удобству тестовой среды. Зафиксируйте его в модели угроз: какие операции допускает token, где он хранится, как быстро пользователь способен повторно аутентифицироваться и что происходит при компрометации.

Ротация refresh token и обнаружение повторного использования

При каждом обновлении сессии выдавайте новый refresh token и отзывайте предыдущий. Повторное предъявление старого token указывает на возможную кражу. В таком случае завершите цепочку сессии, потребуйте повторную аутентификацию и запишите событие безопасности с subject, client_id, временем и correlation ID.

Не передавайте refresh token через URL, не записывайте его в логи и не храните в небезопасном browser storage. Для браузерного приложения продумайте защиту от XSS и CSRF, поскольку компрометация клиентского окружения обходит многие серверные меры.

Ротация ключей подписи JWT без простоя

IdP публикует key set с активным и предыдущим публичными ключами, каждому ключу присваивается отдельный kid. Сначала добавьте новый публичный ключ в JWKS. Затем начните выпуск новых JWT новым закрытым ключом. Предыдущий публичный ключ сохраняйте до истечения максимального срока жизни всех JWT, подписанных старым ключом, с учетом clock skew и кеша JWKS.

1. Создайте новую пару ключей в защищенном хранилище IdP.
2. Опубликуйте новый публичный ключ в JWKS и дождитесь обновления кешей gateway и сервисов.
3. Переключите выпуск JWT на новый kid.
4. Наблюдайте ошибки unknown_kid, сбои подписи и рост 401.
5. Удалите старый публичный ключ после истечения ранее выданных token.

При аварийной компрометации ключа действуйте быстрее: отзовите сессии, сократите прием старых token по допустимому плану, опубликуйте безопасный JWKS и усильте мониторинг. Такой сценарий нужно проверять на тестовом контуре заранее.

Отзыв JWT: когда достаточно короткого TTL, а когда нужна серверная проверка

Самодостаточный JWT нельзя мгновенно отозвать на всех проверяющих узлах без дополнительного состояния. Для обычных операций часто достаточно короткого TTL. Для критичных действий используйте token introspection, denylist по jti, session version в server-side профиле или повторную проверку состояния учетной записи.

Каждая серверная проверка добавляет зависимость, задержку и риск отказа. Определите, какие действия требуют немедленного прекращения доступа: изменение платежных реквизитов, выдача административных прав, экспорт чувствительных данных. Для них выбирайте deny by default при недоступности источника revocation.

Аудит действий и наблюдаемость IAM в микросервисах

Аудит доступа должен отвечать на четыре вопроса: кто выполнил действие, откуда пришел запрос, к какому ресурсу обратился субъект и почему система разрешила или отклонила операцию. Gateway фиксирует периметровую проверку, сервис записывает бизнес-решение, mesh добавляет identity workload и транспортный контекст.

Минимальный состав события аудита доступа

Не записывайте полный JWT, refresh token, Authorization header, cookie сессии и секреты интеграций. Для расследования обычно достаточно jti в безопасно обработанном виде, subject, client_id и метаданных решения. Отправляйте нормализованные audit log в централизованное хранилище или SIEM с контролем срока хранения и доступа.

Метрики и оповещения для контроля доступа

• Доля 401 и 403 с разбивкой по маршруту, client_id и сервису.
• Ошибки issuer, audience, подписи, exp и unknown_kid.
• Сбои загрузки и обновления JWKS.
• Отказы mTLS и неразрешенные workload-вызовы.
• Изменение числа deny-решений после выпуска новой политики.
• Повторное использование refresh token и массовый отзыв сессий.

Оповещения настраивайте на аномальный скачок, а не на единичный 401. Одна ошибка часто означает просроченный token пользователя. Резкий рост 401 после смены kid указывает на проблему JWKS или кеша. Скачок 403 после выката AuthorizationPolicy часто говорит о слишком узком правиле или пропущенной служебной интеграции.

Пошаговое подключение IAM в существующей микросервисной среде

Подключайте обязательные политики поэтапно. Попытка одновременно включить JWT-проверку, strict mTLS и deny by default во всех namespace создает высокий риск блокировки легитимного трафика. Начните с инвентаризации, затем добавляйте проверки в режиме наблюдения и расширяйте охват через canary rollout.

Инвентаризация API, субъектов и доверительных связей

1. Соберите внешние и внутренние endpoint, методы, владельцев сервисов и классификацию данных.
2. Зафиксируйте все субъекты: пользователей, партнерские API-клиенты, ServiceAccount, cron jobs, webhooks и административные инструменты.
3. Для каждого маршрута определите audience, required scopes, тип авторизации и владельца политики.
4. Опишите связи сервисов: источник, получатель, порт, протокол и назначение вызова.
5. Выделите legacy endpoint и временные исключения, назначьте владельца и дату пересмотра.

Тестовый контур должен повторять ключевые сетевые политики production. Для подготовки отдельного Kubernetes-окружения и управляемых инфраструктурных компонентов может подойти облачная инфраструктура Timeweb Cloud, если ее возможности соответствуют требованиям к размещению, журналированию и сетовой сегментации.

Тестовая матрица до включения обязательных политик

Проверяйте негативные сценарии так же тщательно, как успешный путь. Тест без истекшего token, неверного audience и вызова другого tenant не подтверждает, что политика защищает систему.

Контрольный список перед production-включением

• Все публичные маршруты доступны только по HTTPS.
• Gateway и сервисы закрепили алгоритмы подписи JWT, issuer и audience.
• JWKS кешируется контролируемо, процесс ротации kid проверен.
• Access token имеет срок, обоснованный риском, refresh token защищен и ротируется.
• Сервисы проверяют tenant-границы и владение ресурсом.
• Прямой доступ к внутренним API закрыт сетью и mesh-политиками.
• Для meshed workload включен strict mTLS после проверки зависимостей.
• Allow-политики ограничены конкретными ServiceAccount, namespace и маршрутами.
• Audit log содержит allow и deny, но не содержит token и секреты.
• Есть тест аварийной ротации ключа, документированный откат и canary rollout.

После включения наблюдайте отказы по сервисам и клиентам, проверяйте новые интеграции через ту же тестовую матрицу и регулярно пересматривайте временные исключения. IAM в микросервисах сохраняет управляемость, когда каждая граница доверия имеет владельца, проверяемую политику и журнал решения.