Назад к обновлениям
New releaseAug 22, 2026

aws-iam-authenticator v0.7.19

Инструмент для использования учетных данных AWS IAM для аутентификации в кластере Kubernetes

Поделиться

AWS IAM Authenticator for Kubernetes

Инструмент для использования учетных данных AWS IAM для аутентификации в кластере Kubernetes. Первоначальная работа над этим инструментом велась компанией Heptio. Проект получает вклад от многих инженеров сообщества и в настоящее время поддерживается Heptio и инженерами Amazon EKS OSS.

Содержание

Зачем мне это?

Если вы администратор, запускающий кластер Kubernetes в AWS, вам уже нужно управлять учетными данными AWS IAM для подготовки и обновления кластера. Используя AWS IAM Authenticator for Kubernetes, вы избегаете необходимости управлять отдельными учетными данными для доступа к Kubernetes. AWS IAM также предоставляет ряд полезных свойств, таких как независимый аудиторский след (через CloudTrail) и принудительное использование 2FA/MFA.

Если вы создаете установщик Kubernetes на AWS, AWS IAM Authenticator for Kubernetes может упростить ваш процесс начальной загрузки. Вам не нужно будет каким-либо образом безопасно извлекать исходные учетные данные администратора из только что установленного кластера. Вместо этого вы можете создать выделенную роль KubernetesAdmin на этапе подготовки кластера и настроить Authenticator для разрешения входа администраторов кластера.

Как этим пользоваться?

Предположим, у вас есть кластер, работающий в AWS, и вы хотите добавить поддержку AWS IAM Authenticator for Kubernetes. Для этого вам необходимо:

  1. Создать роль IAM, которую вы будете использовать для идентификации пользователей.
  2. Запустить сервер Authenticator в виде DaemonSet.
  3. Настроить API-сервер для взаимодействия с Authenticator.
  4. Настроить kubectl для использования токенов Authenticator.

1. Создание роли IAM

Сначала вам необходимо создать одну или несколько ролей IAM, которые будут сопоставлены с пользователями/группами внутри вашего кластера Kubernetes. Проще всего сделать это, войдя в AWS Console:

  • Выберите опцию «Role for cross-account access» / «Provide access between AWS accounts you own».
  • Вставьте номер вашего AWS account ID (он отображается в правом верхнем углу консоли).
  • К вашей роли не нужно прикреплять дополнительные политики.

Это создаст роль IAM без разрешений, которую смогут принимать авторизованные пользователи/роли в вашем аккаунте. Запомните Amazon Resource Name (ARN) вашей роли — он понадобится вам ниже.

Вы также можете сделать это одним шагом с помощью AWS CLI вместо AWS Console:```sh

get your account ID

ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

define a role trust policy that opens the role to users in your account (limited by IAM policy)

POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')

create a role named KubernetesAdmin (will print the new role's ARN)

aws iam create-role
--role-name KubernetesAdmin
--description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)."
--assume-role-policy-document "$POLICY"
--output text
--query 'Role.Arn'

Вы можете также пропустить этот шаг и использовать:
 - Существующую роль (например, роль кросс-аккаунтного доступа).
 - Пользователя IAM (см. `mapUsers` ниже).
 - EC2-инстанс или федеративную роль (см. `mapRoles` ниже).

### 2. Запуск сервера
Сервер предназначен для запуска на каждом из ваших мастер-узлов в виде DaemonSet с сетевым доступом хоста, чтобы он мог открыть локальный порт localhost.

Пример конфигурации ConfigMap и DaemonSet см. в [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
Перед применением обновите эти значения для вашего кластера:
 - Замените плейсхолдеры IAM ARN (`arn:aws:iam::000000000000:...`) в `config.yaml`.
 - Установите `clusterID` на уникальное значение для вашего кластера.
 - Проверьте, что правила планирования DaemonSet соответствуют меткам/taints ваших control-plane узлов.

Затем разверните его:```sh
kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator

Когда под запущен на узле control-plane, aws-iam-authenticator server создаст webhook kubeconfig на хосте по пути /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml (или по пути, заданному через --generate-kubeconfig).

(Необязательно) Предварительная генерация сертификата, ключа и kubeconfig

Если вы создаёте автоматический установщик, вы также можете легко предварительно сгенерировать сертификат, ключ и файлы webhook kubeconfig с помощью aws-iam-authenticator init. Эта команда сгенерирует файлы и разместит их в настроенных выходных каталогах.

Вы можете запустить её на каждом master-узле перед запуском API-сервера. Вы также можете сгенерировать их до подготовки master-узлов и установить их в соответствующих путях хоста.

Если вы не сгенерируете файлы заранее, aws-iam-authenticator server создаст их по требованию. Это работает, но требует перезапуска Kubernetes API-сервера после установки.

3. Настройте ваш API-сервер для взаимодействия с сервером

API Kubernetes интегрируется с AWS IAM Authenticator for Kubernetes с помощью webhook-аутентификации по токену. При запуске aws-iam-authenticator server будет создан файл конфигурации webhook и сохранён в файловой системе хоста. Вам нужно добавить один дополнительный флаг в конфигурацию вашего API-сервера:``` --authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml

На многих кластерах сервер API запускается как статический под.
Вы можете добавить флаг в `/etc/kubernetes/manifests/kube-apiserver.yaml`.
Убедитесь, что каталог хоста `/etc/kubernetes/aws-iam-authenticator/` смонтирован в под вашего сервера API.
Возможно, вам также потребуется перезапустить демон kubelet на главном узле, чтобы применить обновлённое определение статического пода:```
systemctl restart kubelet.service

4. Создание сопоставлений ролей/пользователей IAM с пользователями/группами Kubernetes

По умолчанию сервер берёт сопоставления исключительно из полей mapUsers и mapRoles своего конфигурационного файла. Подробности см. в разделе Полный формат конфигурации ниже.

С помощью флага --backend-mode можно настроить сервер на получение сопоставлений из двух дополнительных бэкендов: ConfigMap в стиле EKS (--backend-mode=EKSConfigMap) или пользовательских ресурсов IAMIdentityMapping (--backend-mode=CRD). Бэкенд по умолчанию — конфигурационный файл сервера, смонтированный подом сервера, — соответствует значению --backend-mode=MountedFile.

Категории