Аутентификация Kubernetes в AWS EKS с использованием IAM Authenticator

Как Kubernetes интегрируется с аутентификатором AWS IAM

Контекст

Существует другой способ аутентификации в Kubernetes, основанный на различных реализациях облачных провайдеров. В частности, я расскажу об аутентификации, реализованной AWS EKS. Эта статья должна прояснить следующие вопросы.

• Как работает аутентификация в EKS?
• Что такое AWS IAM Authenticator для Kubernetes?
• Что делает «aws eks get-token» в KubeConfig для доступа к кластеру EKS?
• Что такое Configmap «aws-auth» в EKS?
• Как добавить пользователей/роли AWS для доступа к кластеру EKS?
• Как пользователи/роли AWS сопоставляются с пользователями и группами Kubernetes в EKS?
• Как сгенерировать KubeConfig для кластера EKS?
• Как пользователи получают право выполнять определенные действия Kubernetes?

Объем

В этой статье рассказывается о введении в сервис AWS EKS. Вы получите подробное представление о реализации аутентификации Kubernetes с помощью AWS EKS с использованием IAM Authenticator. Он включает только обязательные сведения высокого уровня об авторизации Kubernetes с использованием RBAC.

Предпосылка

• Базовое понимание Kubernetes
• Понимание пользователей и ролей AWS IAM

Что такое ЭКС?

Фон

Как вы знаете, в любом кластере Kubernetes есть плоскость управления (главные узлы) и плоскость данных (рабочие узлы). План управления отвечает за управление рабочими узлами, а рабочие узлы — это место, где рабочая нагрузка приложения развертывается с использованием объектов Kubernetes, таких как модуль, развертывание, службы и т. д.

Настройка, развертывание и управление Kubernetes — очень сложная задача с развитием все большего количества облачных технологий. Большинство компаний хотят быстро вывести свою продукцию на рынок. Они не хотят тратить время на управление кластерами и просто сосредоточены на доставке продукта. Они просто хотят, чтобы их разработчики получили доступ к кластеру для развертывания своих приложений и избавились от управления кластером или, по крайней мере, ограничили управление только рабочими узлами, на которых развертываются приложения.

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

Эластичная служба Kubernetes (EKS)

EKS — это управляемое решение для Kubernetes от AWS.

Я не буду вдаваться в подробности об особенностях ЭКС. Вкратце, плоскость управления — это мастер-узел с высокой доступностью, управляемый AWS в EKS, поэтому пользователи не могут получить доступ к мастер-нодам, а только получить доступ к Kubernetes API для развертывания своих рабочих нагрузок. Существует вариант для управляемых рабочих узлов AWS или самоуправляемых рабочих узлов, к которым пользователи могут получить доступ при необходимости.

AWS IAM Authenticator для Kubernetes

Существует несколько способов аутентификации в кластерах Kubernetes, таких как сертификаты, базовая аутентификация с использованием имени пользователя и пароля и токена аутентификации. Здесь я сосредоточусь на аутентификации, реализованной аутентификатором IAM.

AWS включила встроенную поддержку пользователей и ролей IAM при запуске EKS, чтобы пользователи и роли IAM могли пройти аутентификацию с помощью кластера EKS. Эта аутентификация выполняется с помощью инструмента под названием AWS IAM Authenticator.

AWS IAM Authenticator можно установить вручную в любом кластере Kubernetes, но по умолчанию он устанавливается вместе с EKS.

Рабочий процесс аутентификации

• Клиент выполняет «kubectl get pods», который отправляет запросы на API-сервер Kubernetes. В дополнение к стандартным параметрам запроса он отправляет токен в заголовке авторизации, который представляет собой закодированную в base64 строку подписанных запросов к AWS STS.
• Kubernetes API Server отправляет токен на настроенный сервер аутентификации IAM, работающий в плоскости управления Kubernetes.
• IAM Authenticator извлекает токен из тела запроса, а base64 декодирует токен и проверяет хост URI, путь, параметры запроса, действие и т. д. После успешной проверки он отправляет подписанный запрос в AWS STS для GetCallerIdentity действия.
• AWS STS проверяет подпись для запроса, полученного от средства проверки подлинности IAM, затем выполняет GetCallerIdentity и отправляет ответ, включая сведения об удостоверении IAM, такие как информация о пользователях/ролях.
• IAM Authenticator сопоставляет идентификаторы AWS с идентификаторами K8s, такими как пользователи и группы, на основе правил, настроенных в объекте ConfigMap под названием «aws-auth», доступном в пространстве имен kube-system. Он отправляет идентификаторы K8s обратно на сервер API Kubernetes.
• Kubernetes API Server авторизует пользователей и группы K8s, полученные от аутентификатора IAM, по правилам RBAC из объектов Role и RoleBinding, развернутых в кластере Kubernetes. Если пользователю разрешено действовать, ответ отправляется обратно клиенту kubectl.

Генерация токена с использованием KubeConfig

Я надеюсь, что рабочий процесс аутентификации прояснил бы многие вещи, но все же вы спросите, как генерируется токен, когда мы отправляем запросы с помощью kubectl.

Как вы знаете, Kubectl использует KubeConfig для подключения к кластеру, поэтому после создания кластера в EKS вам необходимо сгенерировать KubeConfig с помощью следующей команды.

aws eks update-kubeconfig --region {region} --name {cluster-name}

Он сгенерирует/обновит ваш файл KubeConfig, доступный в ~/.kube/config. Взгляните на раздел пользователей в этом файле. Он использует другую аутентификацию, которая использует метод «exec» для создания токена с помощью команды «aws eks get-token».

Если вы используете версию интерфейса командной строки AWS старше 1.6.156, вы увидите другие команды в разделе «exec». В этом случае он использует клиент «aws-iam-authenticator» для создания токена доступа, поэтому вам нужно сначала загрузить его, чтобы получить доступ к вашему кластеру.

ПРИМЕЧАНИЕ. При необходимости вы можете указать другой AWS_PROFILE для аутентификации.

Сопоставление удостоверений IAM и удостоверений K8s

Когда вы создаете кластер EKS, он создает ConfigMap по умолчанию с именем «aws-auth» в пространстве имен «kube-system». Пользователь AWS (администратор), создавший кластер, автоматически становится администратором и входит в группу «system:masters» в Kubernetes.

В дополнение к сопоставлению пользователей вы также можете сопоставить роли IAM, поэтому любой пользователь, предполагающий роль IAM, будет сопоставлен с пользователем и группами K8s, настроенными в «aws-auth» ConfigMap.

Авторизация в Кубернете

Это еще не сделано. Сопоставление идентификаторов IAM с идентификаторами K8s не дает идентификаторам K8s никакого доступа к объектам K8s. Вам необходимо создать правила RBAC с использованием объектов Role и RoleBinding в K8s, которые будут разрешать удостоверениям K8s выполнять действия в кластере K8s.

Авторизация Kubernetes — это огромная тема, которая выходит за рамки этой статьи, поэтому я не буду вдаваться в подробности, а попытаюсь осветить ее как часть примера использования в следующем разделе.

ХОРОШО. У меня есть все, но покажите мне в действии. Ну вот

Пример использования — добавление нового пользователя в кластер EKS

Допустим, я хочу добавить нового пользователя в свой кластер AWS EKS и разрешить этому пользователю просто «создавать, перечислять, изменять, удалять модули и развертывания» в пространстве имен «dev» кластера.

Поскольку я создал кластер EKS, я автоматически получаю права администратора для кластера K8s. Когда я запускаю любую команду kubectl, KubeConfig использует профиль «по умолчанию».

Профиль AWS, если он не указан в KubeConfig или не задан с помощью переменной среды AWS_DEFAULT_PROFILE для выполнения команды «exec» в KubeConfig.

Позвольте мне сначала создать пользователя «разработчик» с программным доступом с помощью консоли AWS IAM без каких-либо разрешений AWS. Создайте новый профиль AWS для пользователя «разработчик», используя учетные данные из консоли IAM.

aws configure --profile developer

Теперь давайте возьмем вывод «aws-auth» ConfigMap в YAML, или вы можете отредактировать ConfigMap напрямую.

kubectl -n kube-system get configmap aws-auth -o yaml
or
kubectl -n kube-system edit configmap aws-auth

Мы собираемся добавить сопоставление пользователя IAM с именем «developer» пользователю Kubernetes с именем «k8s-developer» в «aws-auth» ConfigMap и развернуть ConfigMap в кластере K8s.

$ kubectl apply -f aws-auth-configmap2.yaml
configmap/aws-auth configured

Примечание: Помните, что в Kubernetes нет объекта «Пользователь», поэтому мы можем дать любое имя пользователю K8s, и не обязательно, чтобы оно было таким же, как у пользователя IAM.

Мы закончили с отображением, и нам нужно предоставить необходимые разрешения пользователю K8s «k8s-developer» с помощью правил RBAC, поэтому давайте создадим объекты Role и RoleBinding и развернем их в кластере K8s.

$ kubectl apply -f role-rolebinding.yaml
role.rbac.authorization.k8s.io/dev-role created
role.rbac.authorization.k8s.io/dev-role-binding created

Давайте проверим, что пользователь «разработчик» должен иметь возможность создавать и перечислять модули, но не должен иметь возможность перечислять узлы K8s.

# switch to developer profile
$ export AWS_DEFAULT_PROFILE=developer
# create pod
$ kubectl run nginx --image=nginx --restart=Never --port=80
pod/nginx created
# list pod
$ kubectl -n dev get pods
NAME         READY   STATUS    RESTARTS   AGE
nginx        1/1     Running   0          5s
# list k8s nodes
$ kubectl get nodes
Error from server (Forbidden): nodes is forbidden: User "k8s-developer" cannot list resource "nodes" in API group "" at the cluster scope

Если вы переключитесь на профиль AWS «по умолчанию» и попытаетесь перечислить узлы, он должен работать нормально, поскольку он использует пользователя IAM с именем «admin», который сопоставлен с пользователем «admin» и группой «system: master» в K8s, предоставляя администратора. доступ к кластеру K8s.

Заключение

Я надеюсь, что вы получили ответы на все вопросы, которые у вас были в начале статьи, и теперь все было бы достаточно ясно.

Если вам понравилась статья и вы узнали что-то новое, оставьте свое мнение.

Спасибо за прочтение!

Если вам интересно узнать, как получить доступ к сервисам AWS из Kubernetes/EKS, ознакомьтесь с этой статьей.

Ссылки

• https://docs.aws.amazon.com/eks/latest/userguide/cluster-auth.html
• https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html
• https://github.com/kubernetes-sigs/aws-iam-authenticator
• https://kubernetes.io/docs/reference/access-authn-authz/