Предпочтение OpenID Connect или Сертификат клиента X509 * Стратегии аутентификации на основе 1004 * по сравнению с другими при аутентификации пользователей
- сертификаты клиента X509 : достойная стратегия аутентификации, но вам придется регулярно обновлять и распространять сертификаты клиентов
- Stati c Токены : избегайте их из-за их неэфемерного характера
- Bootstrap Токены : то же, что и stati c токены выше
- Basi c Аутентификация : избегайте их из-за того, что учетные данные передаются через сеть в открытом виде
- Токены учетных записей служб : не должны использоваться для конечных пользователей, пытающихся взаимодействовать с кластерами Kubernetes, но они являются предпочтительной стратегией аутентификации для приложений и рабочих нагрузок, работающих в Kubernetes
- OpenID Connect (OID C) Токены : лучшая стратегия аутентификации для конечных пользователей, поскольку OID C интегрируется с вашим поставщиком удостоверений (например, AD, AWS IAM, GCP IAM ... et c)
Советую использовать OpenID Connect. OpenID Connect основан на OAuth 2.0. Однако он разработан с упором на аутентификацию. Явная цель OID C - генерировать так называемый идентификатор-токен. Обычный процесс создания этих токенов почти такой же, как и в OAuth 2.0 . OID C приближает к обеспечению удобного входа в систему, а также позволяет нам начать ограничивать их доступ с помощью RBA C.
Также обратите внимание на Dex который действует как посредник в цепочке аутентификации. Он становится поставщиком идентификации и эмитентом токенов идентификатора для Kubernetes, но сам по себе не имеет никакого чувства идентичности. Вместо этого он позволяет настроить вышестоящего поставщика удостоверений для предоставления удостоверений пользователей.
Как и любой поставщик OID C, Dex поддерживает получение информации о пользователях из GitHub, GitLab, SAML, LDAP и Microsoft. Его плагины провайдера значительно увеличивают потенциал для интеграции с вашей существующей системой управления пользователями.
Еще одно преимущество, которое дает Dex, - это возможность контролировать выпуск токенов ID, например, указывая время жизни. Это также позволяет заставить вашу организацию пройти повторную аутентификацию. С помощью Dex вы можете легко отозвать все токены, но нет возможности отозвать один токен.
Dex также обрабатывает refre sh токенов для пользователей. Когда пользователь входит в систему Dex, ему может быть предоставлен токен id и токен refre sh. Такие программы, как kubectl, могут использовать эти токены refre sh для повторной аутентификации пользователя по истечении срока действия токена id. Поскольку эти токены выпускаются Dex, это позволяет вам остановить обновление конкретного пользователя, отозвав его токен refre sh. Это действительно полезно в случае утери ноутбука или телефона.
Более того, имея центральную систему аутентификации, такую как Dex, вам нужно только один раз настроить вышестоящего провайдера. Преимущество этой настройки заключается в том, что если какой-либо пользователь хочет добавить новую услугу в систему SSO, ему нужно только открыть конфигурацию PR to Dex. Эта настройка также предоставляет пользователям возможность одной кнопкой «отменить доступ» в вышестоящем провайдере идентификации, чтобы отозвать их доступ ко всем нашим внутренним службам. Опять же, это очень полезно в случае нарушения безопасности или потери ноутбука.
Более подробную информацию вы можете найти здесь: kubernetes-single-sign-one-less-identity / , лучшие-практики kubernetes-безопасности .