Блог

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

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

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

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

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

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

Для справки, я использую кластер kubernetes 1.18 EKS, который был создан с помощью 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
}
 

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

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

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

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

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

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

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

[2]: Пример aws-auth configmap

 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 это не единственный источник истины. Первоначальный пользователь поступает из смонтированного файла