Может ли kubectl работать с предполагаемой роли от AWS - PullRequest
Новая
       24

Может ли kubectl работать с предполагаемой роли от AWS

0 голосов
/ 18 января 2019

Я использую Amazon EKS для развертывания в Kubernetes (изначально созданный пользователем-администратором AWS) и в настоящее время испытываю трудности с использованием учетных данных AWS из AWS STS accept-роль для выполнения kubectl команд для взаимодействия со стеком

У меня есть 2 стека EKS на 2 разных учетных записях AWS (PROD и NONPROD), и я пытаюсь получить инструмент CI / CD для развертывания в обоих стеках kubernetes с учетными данными, предоставленными для предполагаемой роли AWS STS, но я ' м постоянно получаю ошибку типа error: You must be logged in to the server (the server has asked for the client to provide credentials).

Я перешел по следующей ссылке, чтобы добавить дополнительную роль AWS IAM в конфигурацию:

Но я не уверен, что не правильно делаю.

Я запустил «aws eks update-kubeconfig», чтобы обновить локальный файл .kube / config, содержимое которого заполнено следующим образом: 

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: [hidden]
    server: https://[hidden].eu-west-1.eks.amazonaws.com
  name: arn:aws:eks:eu-west-1:[hidden]:cluster/demo-eks
contexts:
- context:
    cluster: arn:aws:eks:eu-west-1:[hidden]:cluster/demo-eks
    user: arn:aws:eks:eu-west-1:[hidden]:cluster/demo-eks
  name: arn:aws:eks:eu-west-1:[hidden]:cluster/demo-eks
current-context: arn:aws:eks:eu-west-1:[hidden]:cluster/demo-eks
kind: Config
preferences: {}
users:
- name: arn:aws:eks:eu-west-1:[hidden]:cluster/demo-eks
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - token
      - -i
      - triage-eks
      command: aws-iam-authenticator

и ранее обновлял Kubernetes aws-auth ConfigMap с дополнительной ролью, как показано ниже: 

data:
  mapRoles: |
    - rolearn: arn:aws:iam::[hidden]:role/ci_deployer
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:masters

Мой экземпляр CI / CD EC2 может выполнять роль ci_deployer для обеих учетных записей AWS.

Ожидается: я могу вызвать «kubectl version», чтобы увидеть версии клиента и сервера.

Факт: но я получаю "сервер запросил у клиента учетные данные"

Чего еще не хватает?

После дальнейшего тестирования я могу подтвердить, что kubectl будет работать только из среды (например, моего экземпляра CI EC2 с ролью экземпляра AWS) той же учетной записи AWS, в которой создается стек EKS. Это означает, что мой экземпляр CI из учетной записи A не сможет обмениваться данными с EKS из учетной записи B, даже если экземпляр CI может принять роль от учетной записи B, а роль учетной записи B включена в aws-auth конфигурации kube. счета Б ЭКС. Я надеюсь, что это связано с отсутствием конфигурации, поскольку я нахожу это довольно нежелательным, если инструмент CI не может развертываться на нескольких EKS с нескольких учетных записей AWS с использованием предположения роли.

С нетерпением ждем дальнейшей поддержки @Kubernetes на этом

Ответы [ 2 ]

0 голосов
/ 22 января 2019

С Шаг 1. Создайте кластер Amazon

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

Как вы обнаружили, вы можете получить доступ к кластеру только с тем же пользователем / ролью, который создал кластер EKS.

Существует способ добавить дополнительные роли в кластер после создания, отредактировав созданный aws-auth ConfigMap.

Добавить роль пользователя

Редактируя aws-auth ConfigMap, вы можете добавлять различные уровни доступа в зависимости от роли пользователя.

Сначала вы ДОЛЖНЫ иметь пользователя "system: node: {{EC2PrivateDNSName}}" 

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: <ARN of instance role (not instance profile)>
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Это необходимо, чтобы Kubernetes даже работал, давая узлам возможность присоединяться к кластеру. «Роль ARN экземпляра» - это роль, включающая необходимые политики AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy, AmazonEC2ContainerRegistryReadOnly и т. Д.

Ниже добавьте свою роль 

   - rolearn: arn:aws:iam::[hidden]:role/ci_deployer
     username: ci-deployer
     groups:
       - system:masters

«Имя пользователя» на самом деле может быть установлено на что угодно. Это кажется важным, только если в ваш кластер EKS добавлены пользовательские роли и привязки.

Кроме того, используйте команду «aws sts get-caller-identity» для проверки среды / оболочки, и учетные данные AWS правильно настроены. При правильной настройке get-caller-identity должен возвращать ту же роль ARN, которая указана в aws-auth.

0 голосов
/ 18 января 2019

Похоже, это связано с учетными данными. Некоторые вещи, которые вы можете посмотреть:

  • Переменные окружения учетных данных не установлены в вашем CI?: 

    AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

  • Ваш файл ~ / .aws / credentials неправильно заполнен в вашем CI. С чем-то вроде этого: 

    [default]
aws_access_key_id = xxxx
aws_secret_access_key = xxxx

  • Как правило, переменные окружения имеют приоритет, поэтому в этих переменных окружения также могут быть разные учетные данные.

  • Это также может быть переменная AWS_PROFILE env или конфигурация AWS_PROFILE в ~/.kube/config

    users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws-iam-authenticator
      args:
        - "token"
        - "-i"
        - "<cluster-name>"
        # - "-r"
        # - "<role-arn>"
      # env:
        # - name: AWS_PROFILE <== is this value set
        #   value: "<aws-profile>"

  • Правильно ли установлен профиль под ~/.aws/config?

...