В материале, опубликованном в блоге CNCF, рекомендуется рассматривать контроль доступа к кластерам Kubernetes как часть базового списка настроек наряду с сетями и хранилищем, особенно в самостоятельно размещённых средах, которые обычно не предоставляют готовую интеграцию с IAM или SSO, как это происходит в управляемых сервисах Kubernetes. Ключевая идея заключается в использовании совместимого с OIDC поставщика удостоверений, например Keycloak, с регистрацией клиента в качестве общедоступного клиента, использующего PKCE, а не конфиденциального клиента с общим секретом.
Во многих локальных кластерах доступ основан на постоянном сертификате клиента или токене с длительным сроком действия, который выдаётся один раз. Эти данные остаются действительными даже после ухода сотрудника, изменения его роли или утраты устройства, на котором они хранятся. Кроме того, отзыв доступа требует найти каждую копию файла сертификата или токена — это трудно гарантировать при наличии множества устройств и пользователей. По мере роста числа людей и различий между уровнями разрешений распространение и управление файлами превращаются в постоянную операционную задачу.
Что меняется с OIDC?
Вместо привязки разрешения к файлу сертификата оно связывается с учётной записью пользователя и его членством в группах поставщика удостоверений. Интеграция состоит из трёх взаимосвязанных компонентов: инструмента kubectl с расширением kubelogin или kubectl oidc-login, поставщика удостоверений, который аутентифицирует пользователя и выдаёт ID-токен, и сервера kube-apiserver, который проверяет токен, извлекает имя пользователя и группы, а затем предоставляет Kubernetes RBAC возможность определить разрешённые операции.
Сначала kubectl не подключается к API-серверу для запуска входа. Расширение exec-credential запускает вход через браузер у поставщика удостоверений, после чего возвращает ID-токен в kubectl, чтобы тот отправил его как учётные данные типа Bearer. API-сервер проверяет токен с помощью открытых ключей подписи поставщика удостоверений. Согласно материалу, серверу не требуется постоянное соединение с поставщиком удостоверений, за исключением получения этих ключей при необходимости.
Почему клиент должен быть общедоступным?
Конфиденциальный клиент выпускает секрет, который добавляется в настройки расширения kubelogin и распространяется на каждое устройство, которому требуется доступ. В материале отмечается, что ключ, который необходимо распространять среди всех клиентов, фактически больше не является секретом, а представляет собой общий постоянный идентификатор, который трудно ротировать. Для приложений командной строки и нативных приложений наиболее подходящим вариантом считается общедоступный клиент без секрета с включённым PKCE, или Proof Key for Code Exchange.
Клиент локально создаёт случайное значение и отправляет его хеш в первоначальном запросе входа, а затем доказывает владение исходным значением при обмене кода авторизации на токен доступа. Поэтому тот, кто перехватит только код авторизации, не сможет завершить процесс. В конфигурации Keycloak, приведённой в материале, предлагается отключить аутентификацию клиента, включить стандартный поток, отключить прямые выдачи доступа и принудительно включить PKCE с использованием S256, ограничив адреса перенаправления и веб-источники loopback-адресами, такими как 127.0.0.1 и localhost.
Основные этапы настройки
- Добавить сопоставитель членства в группах в область клиента Keycloak, чтобы внутри ID-токена появлялось утверждение с именем groups.
- Настроить kube-apiserver с помощью таких флагов, как oidc-issuer-url, oidc-client-id, oidc-username-claim и oidc-groups-claim.
- Добавить oidc-ca-file, если поставщик удостоверений использует сертификат, не подписанный общедоступным доверенным центром, чтобы API-сервер мог проверять TLS-соединение и получать ключи подписи.
- Изменить kubeconfig, чтобы использовать запись exec-credential через kubectl oidc-login вместо включения сертификатов или постоянных токенов, не добавляя поле секрета.
- Связать группы поставщика удостоверений с ролями Kubernetes RBAC, например сопоставить группу platform-viewer с ролью view.
Практический эффект и ограничения
После такой интеграции изменения доступа выполняются внутри поставщика удостоверений: пользователя добавляют в группу или удаляют из неё вместо изменения кластера или повторного распространения kubeconfig. Следующий токен, выданный пользователю, содержит новое членство в группе, поэтому применяется связанное с ним правило RBAC. В материале поясняется, что при первом входе открывается браузер, а затем kubelogin использует сохранённый в кэше токен до окончания срока его действия, после чего применяет токен обновления без нового перехода в браузер. Проверить фактические идентичность и группы можно с помощью команды kubectl auth whoami.
Это не означает, что интеграция не предъявляет эксплуатационных требований. Необходимо точно настроить утверждение о группах, проверить сертификат поставщика удостоверений, ограничить адреса перенаправления и убедиться, что роли RBAC отражают требуемые разрешения. Кроме того, материал не приводит независимых измерений времени настройки или стоимости эксплуатации, а лишь оценивает, что подготовка может занять один рабочий период, а не потребовать полной миграции платформы.
Главное преимущество с точки зрения безопасности и администрирования заключается в том, что журналы Kubernetes становятся связаны с фактической идентичностью пользователя. Журналы, использующие общую учётную запись вроде cluster-admin, не различают исполнителей запросов, тогда как каждый запрос, выполненный через OIDC, содержит имя пользователя и связанные с ним группы. Это редакционный вывод, основанный на деталях материала: улучшение касается не только способа входа, но и возможности связать действия с их исполнителями, одновременно превращая выдачу и отзыв разрешений в централизованный процесс управления идентичностями вместо поиска распределённых файлов с учётными данными.