Amazon Web Services — устранение ошибки авторизации сервера в Amazon EKS API Server
В этой статье мы рассмотрим, как пользователи, получившие сообщение об ошибке, должны войти на сервер неавторизованно при подключении к серверу Amazon Elastic Kubernetes Service API.
Здесь у нас есть кластер Amazon EKS, изначально созданный пользователем. Только создатель кластера Amazon EKS имеет разрешение мастера системы на доступ и связь с кластером через командную строку Kubectl.
Давайте сначала проверим нашего пользователя AWS Identity and Access Management. Мы можем настроить это в нашем терминале. В интерфейсе командной строки AWS мы запустим приведенную ниже команду, чтобы показать текущего пользователя, которого мы настроили на нашем локальном компьютере для использования, с помощью следующей команды:
$ aws sts get-caller-identity
Поскольку этот пользователь является тем же создателем кластера, мы обновим файл конфигурации Kube с помощью следующей команды:
$ aws eks update-kubeconfig --name eks-cluster-name --region aws-region
Результирующий файл конфигурации создается по пути Kubeconfig по умолчанию (.kube/config) в вашем домашнем каталоге. Файл kubeconfig — это способ организации информации о кластерах, пользователях, пространствах имен и механизмах аутентификации.
Таким образом, инструмент командной строки Kubectl использует файлы Kubeconfig, чтобы найти необходимую информацию о кластере и понять, как взаимодействовать с сервером API этого кластера.
Теперь у нас обновлен Kubeconfig, и мы являемся создателем кластера. Мы можем выполнить команду Kubectl, такую как Kubectl get-service, как показано ниже:
$ kubectl get svc
Однако, если мы переключим пользователя на любого другого пользователя или возьмем на себя любую роль, мы не сможем общаться с кластером с помощью Kubectl.
Здесь мы вошли в экземпляр эластичного компьютерного облака Amazon. Мы выполним sts, чтобы получить идентификацию вызывающего абонента. Это показывает роль, прикрепленную к экземпляру.
Мы выполним команду update Kubeconfig, как и раньше, и посмотрим, сможем ли мы взаимодействовать с кластером. Теперь применим команду Kubectl. Эта команда создает несанкционированную ошибку, поскольку роль IAM, прикрепленная к экземпляру EC2, не имеет разрешений.
Итак, из окна создателя кластера мы добавим разрешения для роли IAM. Это позволяет экземпляру EC2 взаимодействовать с кластером с помощью команды Kubectl.
Сначала мы добавим роль IAM на карту конфигурации AWS для кластера, используя следующую команду:
$ kubectl edit configmap aws-auth -n kube-system
В разделе «Роли карты» мы добавим роль и предоставим ей системные разрешения. Группа системных мастеров позволяет суперпользователю выполнять любые действия с любым ресурсом. Мы сохраним изменения и повторим попытку из инстанса EC2.
Обратите внимание, что группа системных мастеров позволяет суперпользователю выполнять любые действия с любым ресурсом. Если вы хотите ограничить доступ для этого пользователя, вам необходимо создать роль Kubernetes и привязку роли для этого пользователя, которые сопоставляются в управлении доступом на основе ролей.