AWS IAM Authenticator для Kubernetes

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

Содержание

• Зачем мне это нужно?
• Как это использовать?
• Использование с Kops
• Как это работает?
• Что такое cluster ID?
• Указание учётных данных и использование профилей AWS
• Авторизация API извне кластера
• Устранение неполадок
• Полный формат конфигурации
• Разработка
• Сообщество, обсуждение, вклад и поддержка

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

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

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

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

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

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

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

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

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

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

Вы также можете сделать это за один шаг, используя AWS CLI вместо консоли AWS:

# 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. Запустите сервер

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

Пример конфигурации ConfigMap и DaemonSet см. в deploy/example.yaml. Перед применением обновите следующие значения для вашего кластера:

• Замените заполнители IAM ARN (arn:aws:iam::000000000000:...) в config.yaml.
• Задайте clusterID уникальное значение для вашего кластера.
• Убедитесь, что правила планирования DaemonSet соответствуют меткам/taints ваших узлов control-plane.

Затем разверните его:

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-сервер для взаимодействия с сервером

Kubernetes API интегрируется с 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-сервер работает как статический pod. Вы можете добавить флаг в /etc/kubernetes/manifests/kube-apiserver.yaml. Убедитесь, что каталог хоста /etc/kubernetes/aws-iam-authenticator/ смонтирован в pod вашего API-сервера. Также может потребоваться перезапустить демон kubelet на вашем master-узле, чтобы применить обновлённое определение статического pod:

systemctl restart kubelet.service

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

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

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