Я пытаюсь использовать роли IAM для учетных записей служб в EKS.
https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html
Когда дело доходит до создания роли IAM, которая будет назначена учетной записи службы, я должен создать ее с политикой доверия, которая ссылается на поставщика OIDC определенного кластера.
https://docs.aws.amazon.com/eks/latest/userguide/create-service-account-iam-policy-and-role.html
Конкретно:
Вы также должны создать роль IAM для своих учетных записей служб Kubernetes, прежде чем связывать ее с учетной записью службы. Доверительные отношения ограничиваются вашим кластером и учетной записью службы, поэтому для каждой комбинации кластера и учетной записи службы требуется своя роль.
Эта часть: Доверительные отношения ограничиваются вашим кластером и учетной записью службы. ДЕЙСТВИТЕЛЬНО ограничивает.
Моя проблема заключается в том, что я хотел бы, чтобы кластеры были эфемерными и недолговечными, но я не хочу подправлять политику доверия всех ролей IAM приложений, назначенных учетным записям службы в кластере, каждый раз, когда я перестраиваю кластер. Кроме того, я хотел бы, чтобы один и тот же манифест манифеста kubernetes (для одной и той же учетной записи службы) применялся, идентичный, более чем к одному кластеру, возможно, к кластерам, которые не существовали, когда манифест был написан, и была создана роль приложения IAM.
В предэкс время, при использовании kube2iam, я просто создавал узлы кластера, которые совместно использовали профиль экземпляра, и использовал роль профиля экземпляра в политике доверия ролей IAM, назначенных подам. Это позволило мне написать манифесты, которые будут работать более чем на одном кластере.
Очевидно, я не могу разделить поставщика OIDC между двумя кластерами EKS, подобно тому, как раньше я разделял роль узла (экземпляр-профиль).
Я подхожу к проблеме не с того конца? Я не хочу жестко прописывать в политике доверия ролей IAM приложения что-то (в данном случае провайдера OIDC), специфичное для кластера, потому что кластер не должен быть вечным.Я хочу иметь возможность перестроить его с нуля, не перестраивая роли приложений (или манифесты служебной учетной записи), которые я мог бы запустить на нем.
Я бы придерживался kube2iam, но это не работает с профилями fargate, поэтому роли IAM для учетных записей служб — мое единственное решение.
