Как вернуть доступ к kubectl, потерянный из-за некорректного aws configmap?

Question

[onami]

Предыстория проблемы: в консоли AWS увидел, что под моей админской (не root) по какой-то причине перестали отображаться ноды нашего кластера. Согласно справочной статье нужно было отредактировать configmap.

Я отредактировал configmap следующим образом:

apiVersion: v1
data:
  mapRoles:  <default options>
  mapUsers: |
    - userarn: arn:aws:iam::<root id>:root
    username: #здесь оставил значение пустым
      groups:
      - system:bootstrappers
      - system:nodes

Кончилось, что на все команды kubectl отвечает ошибкой такого рода: Error from server (Forbidden): configmaps "aws-auth" is forbidden: User "" cannot get resource "configmaps" in API group "" in the namespace "kube-system"

Насколько я понимаю, я "понизил" в правах root-пользователя, установив ему группу system:nodes, system:bootstrappers и теперь он не в группе system:masters

На стековерфлоу есть пара подобных вопросов: там пишут, что учетка, из под которой изначально создавали кластер, все равно имеет доступ к его управлению. Но я не понимаю, как всё-таки вернуть доступ. Я воспроизвел эту же ошибку в новом кластере, созданном для этой цели: даже если у меня root, всё равно kubectl не дает выполнять команды.

Обновление #1
Попробовал использовать токен serviceAccount, полученный из файла /var/run/secrets/kubernetes.io/serviceaccount/token в одном из контейнеров.

Команда get nodes заработала, однако отредактировать configmap я не могу

$ kubectl --token=<...> edit configmap aws-auth -n kube-system

Error from server (Forbidden): configmaps "aws-auth" is forbidden: User "system:serviceaccount:kube-system:aws-node" cannot get resource "configmaps" in API group "" in the namespace "kube-system"

Answer 1

[Vitaly Karasik]

учетка, из под которой изначально создавали кластер, все равно имеет доступ к его управлению.

Насколько помню, это действительно так.

даже если у меня root

Речь об учетке AWS

Comments

[onami]

Под рутом я имел в виду root user в консоли AWS.
Под этого же пользователя у меня настроен aws cli и kubectl, под ним я выполнял команды eksctl create cluster, все равно kubectl отфутболивает этого юзера

[Vitaly Karasik]

Понял. Очень странно - вроде бы пользователь который создал кластер не должен терять доступ.

Я сам не пробовал воспроизвести, но тут https://stackoverflow.com/questions/59085639/mista... пишут, что можно "One possibility is if one of your Pods uses a ServiceAccount that has permissions to modify ConfigMaps: log in to the node where the Pod is running with SSH, exec into the Pod's Docker container (docker exec -ti bash), and retrieve the ServiceAccount token in /var/run/secrets/kubernetes.io/serviceaccount/token. You can then use this token to access the cluster from your local machine with kubectl"

[onami]

Vitaly Karasik, я попробовал использовать токен serviceAccount.

Команда get nodes заработала, однако отредактировать configmap я не могу

$ kubectl --token=<...> edit configmap aws-auth -n kube-system

Error from server (Forbidden): configmaps "aws-auth" is forbidden: User "system:serviceaccount:kube-system:aws-node" cannot get resource "configmaps" in API group "" in the namespace "kube-system"

[onami]

Насколько я понимаю проблему, я "понизил" в правах root-пользователя, установив ему группу system:nodes, system:bootstrappers и теперь он не в группе system:masters.

[Vitaly Karasik]

onami

Команда get nodes заработала, однако отредактировать configmap я не могу

добавьте нужные права к роли system:servceaccess

[onami]

Кажется, у serviceAccount нет на это прав

Error from server (Forbidden): error when retrieving current configuration of:
Resource: "rbac.authorization.k8s.io/v1, Resource=roles", GroupVersionKind: "rbac.authorization.k8s.io/v1, Kind=Role"
Name: "example-role", Namespace: "kube-system"
from server for: "F:/downloads/edit-config.yaml": roles.rbac.authorization.k8s.io "example-role" is forbidden: User "system:serviceaccount:kube-system:aws-node" cannot get resource "roles" in API group "rbac.authorization.k8s.io" in the namespace "kube-system"

Манифест такой:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: kube-system
  name: example-role
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "watch", "list"]

[Vitaly Karasik]

возможно нехватает прав в IAM, а не в RBAC, но я не уверен

[onami]

Насколько я понимаю, SystemAccount это внутренняя учетка кубернетеса, не связанная с аутентификацией aws. В общем, патовая ситуация

[Vitaly Karasik]

я не 100% уверен что поможет, но "You can associate an IAM role with a Kubernetes service account" https://docs.aws.amazon.com/eks/latest/userguide/i....

https://nextlinklabs.com/insights/handling-authent...

Мне кажется у всех RBAC сущностей есть IAM роли.

[Vitaly Karasik]

Вы задали очень интересный вопрос! Большинство знакомых, как и я вначале, уверены, что создатель кластера не может потерять к нему доступ.
Я воспроизвел проблему.
Похоже, что что доступ нельзя восстановить без поддержки AWS.

[onami]

> я не 100% уверен что поможет, но "You can associate an IAM role with a Kubernetes service account" https://docs.aws.amazon.com/eks/latest/userguide/i....

Попробовал и этот метод. Не получилось ассоциировать роль.