Вопрос или проблема
Фон
Hashicorp Vault предоставляет способ аутентификации для подключения Pods Kubernetes к Vault, настраивая интеграцию между кластером Kubernetes и Vault.
Вопрос
В документации рекомендуется настроить интеграцию с конечной точкой OIDC Discovery. Я понимаю, что это обычно обеспечивает проверку эмитента, чтобы предотвратить атаки с подменой. Однако в документации также предлагается механизм, позволяющий интеграцию через указание jwks_url и bound_issuer. Параметр bound issuer гласит:
Значение, с которым следует сопоставлять утверждение iss в JWT
Следовательно, проверка эмитента может быть выполнена, если настроен параметр JWKS URL.
Я пытаюсь понять, какие другие присущие риски существуют при выборе этого метода вместо конечной точки OIDC Discovery?
OIDC Discovery предоставляет гораздо больше информации, включая конечную точку JWKS. И, по желанию, способ отзыва доступа ко всем вошедшим в систему конечным точкам.
Например, он может ограничить тип ключа и хэш, используемые, ограничить доступные утверждения и полномочия, а также сообщить, как идентифицировать подлинные запросы.
По сути, bound issuer приемлем, если у вас нет доступа к Discovery, но, когда он доступен, он всегда будет превосходить (и быть более гибким), чем просто задание эмитента.
Ответ или решение
Использование JWKS URL в сравнении с OIDC Discovery Endpoint может вызвать ряд рисков и ограничений, которые стоит учитывать.
1. Ограниченная информация о провайдере
OIDC Discovery Endpoint предоставляет более полную информацию о провайдере идентификации, чем просто JWKS URL. Это включает в себя детали, такие как поддерживаемые алгоритмы подписи, параметры конфигурации для аутентификации, а также спецификации доступных токенов и разрешений. JWKS URL лишь указывает на местоположение публичных ключей, но не предлагает информации о других аспектах аутентификации, таких как требуемые права доступа.
2. Уязвимость к атакам
Хотя привязка к идентификатору bound_issuer может обеспечить некоторую защиту, это не является достаточной мерой для предотвращения всех возможных атак. Необходимость в правильной реализации проверки iss в JWT может быть упущена или неправильно понята, что делает систему уязвимой. OIDC Discovery, напротив, предоставляет дополнительные слои валидации и параметров, что увеличивает безопасность.
3. Управление аннулированием токенов
OIDC Discovery Endpoint предлагает механизмы для аннулирования доступа, что не всегда доступно при использовании JWKS URL. Это может стать критически важным в случаях, когда требуется немедленное аннулирование токена для пользователя, например, при злоупотреблении доступом или смене полномочий.
4. Необходимость ручного обновления
При настройке JWKS URL может понадобиться ручное управление версионированием и обновлениями ключей. Если эти ключи изменятся, сервер аутентификации необходимо будет обновить, что не всегда возможно без простоев в работе системы. OIDC Discovery позволяет автоматизировать этот процесс и снижает вероятность ошибок, связанных с ручным вмешательством.
5. Отсутствие расширяемости
Хоть JWKS URL и позволяет настроить базовую функциональность, это предельно ограничивает возможности дальнейшего расширения функционала. OIDC Discovery поддерживает различные сценарии аутентификации и авторизации, что обеспечивает гибкость интеграции новых функций и улучшений с течением времени.
Заключение
В заключение, использование JWKS URL вместо OIDC Discovery Endpoint может показаться привлекательным в условиях ограниченных ресурсов или простоты интеграции, однако это сопряжено с серьезными рисками, касающимися безопасности, гибкости и управления. Рекомендуется использовать OIDC Discovery для обеспечения более безопасной и управляемой системы аутентификации, особенно в сложных и динамичных средах, таких как Kubernetes.