
Инструмент для использования учетных данных AWS IAM для аутентификации в кластере 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. Для этого вам необходимо:
Сначала вам необходимо создать одну или несколько ролей IAM, которые будут сопоставлены с пользователями/группами внутри вашего кластера Kubernetes. Проще всего сделать это, войдя в AWS Console:
Это создаст роль IAM без разрешений, которую смогут принимать авторизованные пользователи/роли в вашем аккаунте. Запомните Amazon Resource Name (ARN) вашей роли — он понадобится вам ниже.
Вы также можете сделать это одним шагом с помощью AWS CLI вместо AWS Console:```sh
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')
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":{}}]}')
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).
Если вы создаёте автоматический установщик, вы также можете легко предварительно сгенерировать сертификат, ключ и файлы webhook kubeconfig с помощью aws-iam-authenticator init.
Эта команда сгенерирует файлы и разместит их в настроенных выходных каталогах.
Вы можете запустить её на каждом master-узле перед запуском API-сервера. Вы также можете сгенерировать их до подготовки master-узлов и установить их в соответствующих путях хоста.
Если вы не сгенерируете файлы заранее, aws-iam-authenticator server создаст их по требованию.
Это работает, но требует перезапуска Kubernetes 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
По умолчанию сервер берёт сопоставления исключительно из полей mapUsers и mapRoles своего конфигурационного файла. Подробности см. в разделе Полный формат конфигурации ниже.
С помощью флага --backend-mode можно настроить сервер на получение сопоставлений из двух дополнительных бэкендов: ConfigMap в стиле EKS (--backend-mode=EKSConfigMap) или пользовательских ресурсов IAMIdentityMapping (--backend-mode=CRD). Бэкенд по умолчанию — конфигурационный файл сервера, смонтированный подом сервера, — соответствует значению --backend-mode=MountedFile.