Всем привет, небольшой вопрос по EKS. Я залогинился под IAM ролью,

которую используют воркер ноды (она весьма ограниченная, там сплошные describe и readonly) и смог увидеть поды в неймспейсах.
И даже запустить новый.
Может кто видел какую доку на это? Я не до конца понимаю, почему оно позволяет это делать.
Учитывая, что группа (в aws-auth) для воркер нод имеет только bootstrap разрешения в RBAC EKS
Т.е. IAM не дает полномочий на запуск пода, RBAC тоже не дает, но сделать это почему-то получается

покажи aws-auth целиком

там каждая нода получает куберовскую роль system:node, которая и позволяет запускать поды и многое другое

В офф доке пишут, что system:node депрекейтнутый CR, но при это я его вижу даже в своем 1.26 кластере.

Примерно так mapRoles: ---- - groups: - system:bootstrappers - system:nodes rolearn: arn:aws:iam::111122223333:role/my-node-role username: system:node:{{EC2PrivateDNSName}}

насколько я понял, в EKS включен admission plugin NodeRestriction и типа это ограничивает кубелеты в том, что они реально могут делать

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

а где запускаются эти поды? На других нодах тоже? Секреты можете смотреть?

Секреты смотреть нельзя, но можно запустить привелигерованный под примаунченный к локалхосту

по идее это как раз то, что должен уметь делать кубелет, разве не так?

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

не совсем понял. А в чем с точки зрения кубера отличия кубелета от ноды? Кубелет должен уметь запускать поды, монтировать секреты в том числе.

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

прочитайте как работает instance profile

почитайте про Kubernetes RBAC, aws-auth и EC2 metadata. Оно так и должно работать

"Так" - это как? Сервер имея права только на чтение и джойн, начинает создавать привилигированные поды.

кубелет имеет права не только на чтение. Он на дофига чего имеет права в кубере. Вы смотрите только на ридонли и джойн роль, но есть и другая роль под названием system:node, к которой у кубелета тоже есть доступ

Верно, эта роль у кублета по дизайну. Но не у сервера

что вы понимаете под “сервером”?

Воркер нода где запущен кублет

как вы думаете, каким образом кубелет получает свой токен, с помощью которого он общается с Kubernetes API?

Через сертификат который был получен на этапе бутстрапа кубелета

хорошо, а каким образом Kubernetes API выдал ему этот сертификат? Он разве кому угодно может сертификат выдать?

Сертификат был запрошен нодой. Нода имеет права в IAM на дескрайб всего необходимого и права в RBAC кубера для получения сертификата - system:node-bootstrapper

каким образом нода аутентифицируется в Kubernetes API?

Через IAM

совершенно верно. Через IAM нода получает доступ к Kubernetes API. Вместе с этим она получает доступ к роли system:node

А вот и нет

почему? В aws-auth же это написано

apiVersion: v1 data: mapAccounts: | [] mapRoles: | - "groups": - "system:bootstrappers" - "system:nodes" "rolearn": "arn:aws:iam::1111111111:role/eks-node-group-20230314125042417300000001" "username": "system:node:{{EC2PrivateDNSName}}"

"username": "system:node:{{EC2PrivateDNSName}}"