Ошибка kubectl. Вы должны войти на сервер (неавторизованный) при доступе к кластеру EKS

Я пытался следовать руководству по EKS. Когда я попытался вызвать kubectl get service, я получил сообщение: error: вы должны войти на сервер (неавторизованный). Вот что я сделал:
1. Создал кластер EKS.
2. Создал конфигурационный файл следующим образом:

apiVersion: v1
clusters:
- cluster:
    server: https://*********.yl4.us-west-2.eks.amazonaws.com
    certificate-authority-data: *********
  name: *********
contexts:
- context:
    cluster: *********
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: heptio-authenticator-aws
      args:
        - "token"
        - "-i"
        - "*********"
        - "-r"
        - "arn:aws:iam::*****:role/******"
  1. Загрузили и установили последнюю версию aws cli
  2. Ran aws настроит и установит учетные данные для моего пользователя IAM и региона как us-west-2
  3. Добавлена политика для пользователя IAM для sts: AssumeRole для роли EKS и настроена как доверенная связь
  4. Настройка kubectl для использования файла конфигурации

Я могу получить токен, когда я запускаю лексику heptio-authenticator-aws -r arn: aws: iam :: **********: role/********* -i my -cluster-ame Однако, когда я пытаюсь получить доступ к кластеру, я все время получаю ошибку: вы должны войти на сервер (неавторизованный)

Любая идея, как решить эту проблему?

Ответы

Ответ 1

При создании кластера Amazon EKS объект IAM (пользователь или роль), который создает кластер, добавляется в таблицу авторизации RBAC Kubernetes в качестве администратора. Первоначально только тот пользователь IAM может делать вызовы на сервер API Kubernetes, используя kubectl.

ЭКС-документы

Поэтому для добавления доступа другим пользователям aws сначала необходимо отредактировать ConfigMap, чтобы добавить пользователя или роль IAM в кластер Amazon EKS.

Вы можете отредактировать файл ConfigMap, выполнив: kubectl edit -n kube-system configmap/aws-auth, после чего вам будет предоставлен редактор, с которым вы сопоставляете новых пользователей.

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::555555555555:role/devel-worker-nodes-NodeInstanceRole-74RF4UBDUKL6
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters
  mapAccounts: |
    - "111122223333"

mapUsers на mapUsers куда вы добавляете пользователя ops вместе с mapAccounts которая отображает учетную запись пользователя AWS с именем пользователя в кластере Kubernetes.

Однако никаких разрешений в RBAC только этим действием не предоставляется; вы все равно должны создать привязки ролей в вашем кластере, чтобы предоставить этим объектам разрешения.

Как указано в документации Amazon (iam-docs), вам необходимо создать привязку роли в кластере kubernetes для пользователя, указанного в ConfigMap. Вы можете сделать это, выполнив следующую команду (kub-docs):

kubectl create clusterrolebinding ops-user-cluster-admin-binding --clusterrole=cluster-admin --user=ops-user

который предоставляет cluster-admin ClusterRole пользователю с именем ops-user во всем кластере.

Ответ 3

Я прокомментировал последние две строки конфигурационного файла

# - "-r"
# - "arn:aws:iam::**********:role/**********"

и это сработало, хотя я понятия не имею, почему

Ответ 4

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

Ответ 5

Вам необходимо создать кластер под тем же профилем IAM, с которым вы обращаетесь, через AWS cli.

С другой стороны, внутри ~/.aws/credentials, профиль, который обращается к kubectl, должен совпадать точно с тем же IAM, который использовался для создания кластера.

Моя рекомендация - использовать AWS cli для создания ваших кластеров, поскольку создание из графического интерфейса может быть более запутанным, чем полезным. Руководство " Начало работы" - это лучший выбор для запуска и запуска.

Ответ 6

Я просто отладил эту проблему. У меня вопрос. Вы используете это в корпоративной сети Wi-Fi? Если да, можете ли вы создать экземпляр EC2, а затем проверить, можете ли вы сделать kubectl get svc?

Кроме того, попробуйте, если эта команда работает kubectl get svc ---insecure-skip-tls-verify

Ответ 7

Это происходит также со мной в локальной среде на мини-кубе, независимо от EKS. Моя проблема связана с этой проблемой: https://github.com/kubernetes/kubernetes/issues/76774

Решение, которое я принял, - удалить каталоги кеша kubectl: rm -rf ~/.kube/{cache,http-cache}. Я думаю, это единственный обходной путь на момент написания.