Kubernetes является одной из самых популярных платформ для оркестрации контейнеров, широко используемой в производственной среде благодаря своей гибкости и масштабируемости. Одной из ключевых возможностей Kubernetes является поддержка аутентификации через OpenID Connect (OIDC), которая позволяет интегрировать кластер с внешними системами удостоверения личности и использовать JWT токены (JSON Web Tokens) для аутентификации и авторизации. Однако для успешной работы такой интеграции требуется безопасно предоставить доступ к OIDC JWKS (JSON Web Key Set) эндпоинтам, которые отвечают за публикацию публичных ключей для проверки подписи JWT. В то же время, в продакшен-окружениях, согласно лучшим практикам безопасности, часто отключается анонимный доступ к Kubernetes API Server, что создает проблему с доступностью этих эндпоинтов для внешних систем. Чтобы решить эту проблему, появилось специализированное решение — k8s-jwks-proxy, облегчающее безопасное предоставление OIDC JWKS эндпоинтов без угроз для безопасности кластера.
Для начала стоит понимать, какую роль играют эндпоинты /.well-known/openid-configuration и /openid/v1/jwks при работе с OIDC в Kubernetes. Первый эндпоинт предоставляет метаданные провайдера OpenID, включая информацию о поддерживаемых типах ответов и местоположении JWKS. Второй отвечает за публикацию ключей шифрования, с помощью которых внешние сервисы могут проверить подлинность JWT, выпущенных Kubernetes. Если эти URL недоступны для внешних систем, то невозможно обеспечить корректную аутентификацию и авторизацию, что влечет за собой перебои в работе интеграций и сервисов.
Одним из принципиальных барьеров является отключение анонимного доступа в Kubernetes API (параметр --anonymous-auth=false), что логично и оправдано в целях безопасности, поскольку предотвращает несанкционированный доступ к API. Однако это также делает OIDC эндпоинты недоступными извне. Есть классическая рекомендация по снижению уровня безопасности для экспонирования этих URL, но это недопустимо в продуктивных кластерах. Именно здесь на помощь приходит k8s-jwks-proxy — легковесный обратный прокси, написанный на Go и разработанный специально для безопасного форвардинга запросов к вышеуказанным OIDC эндпоинтам Kubernetes API Server. Он интегрируется в кластер как отдельное приложение, использует механизмы аутентификации с помощью сервисного аккаунта, тем самым не требует отключения или изменения параметров безопасности самого API Server.
Прокси гарантирует, что запросы к /.well-known/openid-configuration и /openid/v1/jwks будут корректно и только безопасно обработаны и переданы, доступно предоставляя необходимые данные внешним системам. Развертывание k8s-jwks-proxy в кластере максимально простое, особенно при использовании Helm чарта, который обеспечивает быструю и удобную установку и настройку приложения. При этом прокси поддерживает конфигурацию с включенным ingress, что позволяет выставить OIDC эндпоинты под своим кастомным доменом с возможностью автоматической генерации TLS сертификатов через такие инструменты как cert-manager. Это делает экспонирование JWKS URL не только безопасным, но и удобным для использования с привычными HTTPS адресами.
Одним из успешных сценариев применения k8s-jwks-proxy является создание локальных тестовых кластеров с помощью kind, в которых одновременно настраивается кастомный OIDC issuer и публичный доступ к соответствующим эндпоинтам. Такой подход значительно облегчает разработку, тестирование и интеграцию систем аутентификации в Kubernetes, не жертвуя безопасностью и не требуя сложных манипуляций с API Server. Преимущества использования k8s-jwks-proxy проявляются в нескольких аспектах. Во-первых, безопасность соблюдается на высоком уровне, так как отсутствует необходимость включать анонимный доступ или расширять RBAC права ресурсам. Во-вторых, идет значительная экономия времени и ресурсов, поскольку не требуется создавать и поддерживать дополнительные сертификаты и сложные механизмы проксирования.
В-третьих, решение полностью соответствует современным требованиям для production-сред и демонстрирует стабильность, проверенную сообществом и практикой. Помимо k8s-jwks-proxy, существует понимание необходимости структурированной аутентификации в Kubernetes 1.30 и выше, где добавлены новые механизмы создания и использования JWT-совместимых EC ключей и их безопасного экспонирования в виде JWKS. Эти возможности позволяют еще более гибко и надёжно интегрировать сервисы и приложения с Kubernetes и внешними провайдерами идентификации. В заключение, экспонирование OIDC JWKS эндпоинтов без снижения безопасности кластера становится реальностью благодаря таким инструментам, как k8s-jwks-proxy.
Это повышает уровень доверия между системами, упрощает задачи интеграции и оптимизирует процессы аутентификации. Для разработчиков и администраторов Kubernetes важно освоить данный подход и внедрить его в свои сценарии, чтобы обеспечить безопасный, стабильный и масштабируемый доступ к критически важным аутентификационным сервисам. Такая практика способствует развитию экосистемы Kubernetes и открывает новые возможности для построения современных облачных инфраструктур.
