Карта границ для AKS-приложения, которое не может получить токен Microsoft Entra для Azure Managed Redis: как проверить service account, OIDC federation, аудиторию токена и TLS без раскрытия секретов.
Нарисуйте цепочку до Redis
Запишите пять узлов: pod, Kubernetes service account, проецируемый OIDC-токен, federated identity credential в Microsoft Entra и клиент Azure Managed Redis. Ошибка «не удалось получить токен» возникает до проверки прав Redis, а отказ Redis после получения токена — уже другой слой. Зафиксируйте точный класс исключения и время, но не печатайте содержимое JWT. Такое разделение защищает от бессмысленной смены ролей, когда pod вообще не получил токен для обмена.
Проверьте service account внутри pod
Убедитесь, что workload запущен именно с ожидаемым service account и что pod содержит признаки включённой Azure Workload Identity. Сравните имя namespace и service account с subject федеративной учётной записи. Проверка должна выполняться на одном тестовом pod без изменения production deployment. Если pod использует default service account или старый экземпляр был создан до изменения аннотаций, дальнейшая проверка Entra будет описывать не ту идентичность.
Сверьте три поля федерации
Microsoft описывает сопоставление issuer кластера, subject service account и audience проецируемого токена с federated identity credential. Сравните эти значения как строки, скрыв идентификаторы в журнале. Особенно важны схема и завершающий слеш issuer, namespace в subject и ожидаемая audience. Не создавайте несколько почти одинаковых federated credentials «на пробу»: это затрудняет аудит. Сначала найдите первое несовпадение и измените только его в согласованном тестовом контуре.
Отделите получение токена от входа в Redis
После успешного получения токена проверьте, что клиент подключается к Azure Managed Redis с включённым TLS и использует поддерживаемую Entra-аутентификацию, а не одновременно старый ключ доступа. Зафиксируйте, обновляет ли библиотека токен до истечения срока действия. Если первый вход успешен, а длительная сессия позже разрывается, это отдельный сценарий обновления токена; он не доказывает дефект OIDC federation. Не отключайте проверку сертификата ради диагностики.
Соберите безопасные доказательства
Для эскалации укажите версию AKS и библиотеки клиента, имена namespace и service account в маскированном виде, совпадение issuer, subject и audience, точный этап ошибки, время и корреляционный идентификатор. Отдельно отметьте, был ли токен получен и дошёл ли запрос до Redis. Не прикладывайте JWT, client secret, tenant ID целиком, адрес Redis с приватными параметрами или вывод всех переменных окружения. Полезен результат одного воспроизводимого pod, а не поток несвязанных журналов.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 29 июля 2026 года по обезличенному сигналу Microsoft Q&A и официальной документации Azure; токены, идентификаторы арендатора и конфигурации не воспроизводились.
Источники и проверка
- Microsoft Learn — аутентификация Microsoft Entra в Azure Managed Redis проверено 2026-07-29
- Microsoft Learn — обзор Microsoft Entra Workload ID в AKS проверено 2026-07-29
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.