Как пользователь "создатель кластера" кластера AWS EKS сопоставляется с группой RBAC "система: мастера"?

Я пытаюсь понять, как управляются авторизации RBAC для первого пользователя, который создает кластер EKS в AWS.
Или, другими словами: как создатель кластера сопоставляется с группой "система: мастера" в RBAC?

Я знаю, что в этом документе говорится: "Когда вы создаете кластер Amazon EKS, пользователю или роли объекта IAM, например федеративному пользователю, который создает кластер, автоматически предоставляются разрешения system:masters в конфигурации RBAC кластера".
И я понимаю, как clusterrole cluster-admin и clusterrolebinding cluster-admin предоставляют полные права администратора всем членам группы "система: мастера".

Что я не могу понять, так это как / где пользователь-создатель кластера сопоставлен с этой группой? ("автоматически предоставленная" часть документа)

PS: Я знаю, что для добавления дополнительных пользователей / ролей я должен использовать конфигурационную карту aws-auth, но этот первый пользователь здесь не определен и все еще имеет доступ к кластеру.

Если кто-нибудь может меня просветить, пожалуйста?

Заранее спасибо!

Для записи я использую кластер EKS kubernetes 1.18, который был построен с помощью terraform через модуль сообщества здесь:

module "cluster" {
  source  = "terraform-aws-modules/eks/aws"
  version = "13.2.1"

  cluster_version = "1.18"
  cluster_name    = "memorandom-${local.id}"
  vpc_id          = module.vpc.vpc_id
  subnets         = module.vpc.private_subnets

  write_kubeconfig = false
  manage_aws_auth  = true

  worker_groups = [
    {
      instance_type = "t3.medium"
      asg_max_size  = 3
      key_name      = "pbenefice"
    }
  ]

  tags = local.tags
}
Источник

3 ответа

Решение

Поэтому я обратился в службу поддержки AWS по этой теме. Подводя итог, ответ был следующим: "Большая часть того, о чем вы спрашиваете, является конфиденциальной информацией и не может быть раскрыта".

Я вставляю полный ответ сюда:

Благодарим за обращение в службу поддержки AWS Premium. Меня зовут *, и я понимаю, что вам интересно узнать о деталях реализации того, что создатель кластера является частью группы system: masters.

Большая часть того, о чем вы спрашиваете, является конфиденциальной информацией и не может быть раскрыта.

Однако я могу вам сказать, что в плоскости управления EKS есть компонент аутентификатора. Вы можете включить журналы для этого, как описано здесь [1].

Лично мне нравится думать об этой "автоматически предоставляемой" части документов как о воображаемом постоянном объекте только для чтения под mapUsers:раздел файла configmap aws-auth. Воображаемый, потому что он не реализован в конфигурационной карте aws-auth, но предоставленные ему разрешения такие же, как если бы он был там. В приведенном ниже примере [2] я создал воображаемый пользовательский объект-создатель кластера, который показывает эффективную реализацию.

[1]: Ведение журнала уровня управления Amazon EKS - https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html

[2]: Пример файла конфигурации aws-auth

apiVersion: v1
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
  mapUsers: |
    # The way EKS currently bootstraps your cluster permissions, you can think of the cluster-creator having a
    # read-only permanent entry here - the effective permissions are the same
    - userarn: arn:aws:iam::111122223333:user/cluster-creator
      username: cluster-creator
      groups:
        - system:masters
    # In an actual aws-auth configmap, the cluster-creator entry above isn't there and
    # only the mapUsers below would be shown
    - userarn: arn:aws:iam::111122223333:user/admin
      username: admin
      groups:
        - system:masters
    - userarn: arn:aws:iam::111122223333:user/ops-user
      username: ops-user
      groups:
        - system:masters

Наиболее важные практические соображения относительно разрешений RBAC создателя кластера:

  • объект IAM (пользователь или роль), создавший кластер, всегда будет иметь права администратора (разрешения системы: мастера)
  • если объект IAM удаляется без добавления других объектов IAM с необходимыми разрешениями в конфигурационную карту aws-auth - у вас есть два варианта:
    1. вы должны либо воссоздать объект IAM с тем же именем, чтобы восстановить доступ к вашему кластеру, либо
    2. удалить кластер и создать новый кластер, используя новый объект IAM

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

Источник

Обратите внимание, что aws-auth configMapэто не единственный источник истины. Первоначальный пользователь приходит из MountedFile

Источник

реализация карты aws-auth для IAM — сопоставление RBAC Kubernetes выполняется с помощью развернутого на плоскости управления сервера динамического веб-перехватчика (веб-перехватчик доступа).

  • создатель кластера отображается в том же файле конфигурации веб-перехватчика, который используется для аутентификации и авторизации других запросов на карте aws-auth.
  • создатель кластера просто не прописывается в карту aws-auth во избежание ошибочных правок или изменений —some entity must always have access to the clusterэто конструктивное соображение для этого
  • хотя мы могли удалить создателя кластера IAM из AWS IAM, поэтому кластер знает создающую сущность, но у нас больше нет этой сущности в учетной записи AWS.
Источник
Другие вопросы по тегам