Подключение к Kubernetes

Kubron определяет тип учётных данных по выбранному контексту kubeconfig. Вручную выбирать режим подключения не требуется. Если нужен интерактивный вход, Kubron открывает диалог с запросом и проводит пользователя через необходимые шаги.

Поддерживаемые способы входа

• Статические учётные данные: bearer-токены, basic credentials и клиентские сертификаты, встроенные в данные kubeconfig.
• OIDC: поддерживаемые сценарии oidc-login (password, authorization code и device code), а также legacy refresh flow auth-provider: oidc — в зависимости от конфигурации провайдера идентификации.
• Azure AKS: режимы Azure kubelogin device-code, service-principal с client secret и логин/пароль (ROPC).
• AWS EKS: kubeconfig с aws eks get-token и aws-iam-authenticator: ключи доступа, временные ключи с session-токеном, необязательная роль (role-arn) или IAM Identity Center (код устройства).
• Google GKE: kubeconfig с gke-gcloud-auth-plugin: ключ сервисного аккаунта или, если настроено, ваш собственный аккаунт Google.
• Остальные exec-плагины: обрабатываются по правилам соответствующей платформы, описанным ниже.

Доступные варианты входа зависят от kubeconfig и провайдера идентификации. Неподдерживаемые режимы отклоняются: Kubron не подставляет вместо них учётные данные из окружения сервера.

Desktop

Desktop подключается к Kubernetes API с вашего компьютера.

• Импортируйте kubeconfig-файл или вставьте его содержимое. Если контекстов несколько, выберите нужный.
• Если настроенный сценарий поддерживается нативным провайдером, Kubron запросит необходимые данные или откроет вход через браузер/device code.
• Kubernetes exec credential plugins могут запускаться локально, если исполняемый файл установлен в PATH. Перед запуском Kubron показывает команду, аргументы и имена переменных окружения (без их значений) и запрашивает подтверждение. При изменении команды подтверждение потребуется снова.
• Если нативный провайдер не поддерживает режим exec, Kubron может использовать настроенный локальный плагин после подтверждения.

Exec-плагин — исполняемый код. Импортируйте kubeconfig только из доверенных источников и проверяйте команду перед подтверждением запуска.

Web

Web-сервер подключается к кластерам из собственной сетевой среды сервера. Он не может читать файлы с вашего компьютера и никогда не запускает произвольные команды из загруженного kubeconfig.

• Статические учётные данные должны быть встроены в kubeconfig. Локальные пути к файлам серверу недоступны.
• Поддерживаемые OIDC-сценарии используют универсальный диалог входа. В зависимости от IdP и его настроек это может быть ввод учётных данных, device-code или завершение browser redirect.
• Для Azure AKS поддерживаются настроенные режимы kubelogin device-code, service-principal с client secret и ROPC. ROPC может быть недоступен, если tenant требует MFA или Conditional Access.
• AWS EKS и Google GKE тоже обслуживаются нативными провайдерами: Kubron сам выпускает токен EKS и входит в GKE по ключу сервисного аккаунта или аккаунту Google. См. AWS EKS и Google GKE.
• Для exec без нативного провайдера Kubron показывает точную команду, которую нужно выполнить на вашем компьютере, и принимает полученный токен или JSON ExecCredential. Сервер эту команду не запускает.

Сервер не использует Azure CLI с вашего компьютера, облачные credentials из окружения, домашний каталог или metadata service. Режимы AKS managed identity, Azure CLI, azd и workload identity этим провайдером не поддерживаются.

AWS EKS

Для кластера EKS (aws eks get-token или aws-iam-authenticator в kubeconfig) Kubron сам выпускает токен и плагин не запускает. Окно входа запрашивает:

1. Способ входа. Напишите одно слово: keys (постоянные ключи IAM-пользователя), session (временные ключи с session-токеном) или sso (IAM Identity Center). Если kubeconfig не задаёт регион и имя кластера, введите их тоже.
2. Данные. Для keys и session: идентификатор ключа и секретный ключ (для session ещё session-токен). Ключи, начинающиеся с ASIA, без session-токена не принимаются. Для sso: адрес портала (start URL), регион SSO, идентификатор аккаунта и имя роли.
3. Только для sso: вход по коду устройства.

Если в kubeconfig указана роль (role-arn), токен выпускается от имени этой роли после AssumeRole.

Что важно знать:

• Ключи сохраняются зашифрованно в области вашего пользователя, поэтому повторные подключения не спрашивают их снова. Примерно раз в 14 минут, при выдаче токена, Kubron проверяет ключи запросом STS GetCallerIdentity (для роли — AssumeRole). Отозванные или просроченные ключи приводят к новому запросу. Если AWS временно недоступен, токен всё равно выпускается локально по сохранённым ключам.
• Для SSO сохраняются временные ключи роли (около часа). Когда они истекают, Kubron пробует обновить их сам; если не удаётся, окно просит войти заново.
• Учётные данные самого сервера (переменные окружения, ~/.aws, профили, метаданные инстанса) никогда не используются, а profile из kubeconfig игнорируется.
• Отключиться от кластера удаляет сохранённые ключи в Kubron, но не отзывает их в AWS. Удалите или деактивируйте ключ в IAM самостоятельно.
• Не поддерживаются: неизвестное значение authenticator, изолированные разделы AWS (iso*) и --cluster-id (Outposts). Для них используйте токен, полученный вручную.
• Вход через IAM Identity Center пока проверен только на тестовом сервере, а не на реальном AWS.

Выдавайте пользователям Kubron ключи отдельных IAM-пользователей или ролей с минимальными правами. Доступ к самому кластеру задаётся через aws-auth или EKS access entries. Ротируйте ключи по расписанию.

Google GKE

Для кластера GKE (gke-gcloud-auth-plugin в kubeconfig) Kubron входит сам вместо запуска плагина. Есть два способа:

1. Свой аккаунт Google, если настроен OAuth-клиент. В Web-версии его задаёт администратор через KUBRON_GKE_OAUTH_CLIENT_ID и KUBRON_GKE_OAUTH_CLIENT_SECRET (см. развёртывание). В Desktop вы настраиваете его в Settings, в карточке Вход через Google для GKE. Откроется страница Google, после входа браузер вернётся в Kubron. Если страница возврата не открывается (на сервере нет KUBRON_PUBLIC_URL или не удалось открыть локальный порт), скопируйте её адрес целиком и вставьте в поле. Kubron сохранит refresh-токен зашифрованно и дальше обновляет доступ сам.
2. Ключ сервисного аккаунта (JSON-файл, который выдаёт Google Cloud): вставьте его содержимое в поле.

Если клиент Google настроен, новый вход идёт через аккаунт Google; ранее сохранённый ключ продолжает работать, а ключ, который перестал приниматься, запрашивается снова.

В Desktop создайте в Google Cloud OAuth-клиент типа Desktop app, введите его идентификатор и секрет в карточке и перезапустите Kubron. Секрет хранится зашифрованно и больше не показывается.

Что важно знать:

• Ключ обменивается на токен доступа по фиксированному адресу https://oauth2.googleapis.com/token. Адрес token_uri из файла игнорируется.
• Учётные данные Google самого сервера (Application Default Credentials, metadata-сервер, переменные окружения, файлы gcloud) никогда не используются.
• Сохранённый ключ хранится зашифрованно, токен живёт около часа. Размер файла ключа — не больше 16 КиБ.
• Отключиться от кластера удаляет сохранённый ключ в Kubron, но не отзывает его у Google. Удалите ключ в Google Cloud. Доступ, выданный аккаунту Google, отзывается на странице аккаунта Безопасность (доступ сторонних приложений).
• Workload Identity Federation, authorized_user и impersonated_service_account не поддерживаются. Используйте токен, полученный вручную.

Заведите отдельный сервисный аккаунт на кластер или группу кластеров с минимальными ролями, выдайте его client_email права через Kubernetes RBAC, ротируйте ключи и удаляйте неиспользуемые в Google Cloud.

Чья Kubernetes identity используется?

Статические учётные данные остаются общими для кластера. Интерактивные учётные данные сохраняются в области пользователя, который проходит вход, поэтому каждый участник может подключаться под собственной Kubernetes identity. Итоговый доступ ограничивается одновременно разрешениями Kubron и Kubernetes RBAC.

Пароль личного интерактивного входа не сохраняется. Если провайдер поддерживает refresh token, Kubron хранит его непрозрачное состояние в зашифрованном виде.

Общая учётная запись команды

Для кластера команды, который входит через провайдера, администратор кластера может включить «Общую учётную запись команды» в окне добавления или правки. Администратор один раз входит при подключении; провайдер проверяет вход, а Kubron хранит его зашифрованным для всей команды. Остальные участники подключаются под этой записью и, пока её нет, видят «обратитесь к администратору кластера». Если пароль в провайдере сменился, нажмите «Забыть общий вход» в настройках кластера. Включение и выключение опции стирает сохранённые входы этого кластера.

Решение проблем

• Диалог сообщает, что режим не поддерживается: проверьте настройки аутентификации users[].user выбранного контекста kubeconfig. Некоторые облачные режимы намеренно не поддерживаются.
• Device sign-in не завершается: убедитесь, что код введён в правильном tenant и не истёк.
• Не работает вход AKS по логину и паролю: ROPC часто блокируется MFA или Conditional Access. Используйте device-code или другой режим, разрешённый администратором.
• EKS снова просит ключи: сохранённые ключи отозваны или просрочены, либо закончились ключи роли SSO. Введите их заново.
• GKE пишет, что ключ — невалидный JSON или не поддерживается: вставьте файл сервисного аккаунта целиком, вместе с фигурными скобками. Другие виды учётных данных не поддерживаются.
• Exec-плагин недоступен в Web: это ожидаемо. Выполните показанную команду на своём компьютере и вставьте токен или результат ExecCredential.

Команды и совместный доступ · Безопасность и управление доступом