Невозможно изменить (исправить) docker идентификатор изображения существующего определения развертывания kubernetes на eks (aws)

Question

Я создал определение CodePipeline для aws. Сначала я создаю docker образ и отправляю его в ecr (реестр контейнеров на aws). Когда образ docker был отправлен в реестр, я вызываю лямбда-функцию, которая должна обновить определение существующего развертывания, заменив docker идентификатор изображения в этом определении развертывания. Лямбда-функция реализована с использованием nodejs, принимает недавно отправленный идентификатор изображения и пытается исправить определение развертывания. Когда он пытается залатать развертывание, я получаю ответ, подобный приведенному ниже.

body: {
kind: 'Status',
apiVersion: 'v1',
metadata: {},
status: 'Failure',
message: 'deployments.apps "arch-app" is forbidden: 
          User "system:serviceaccount:arch-user:default" cannot patch resource "deployments" 
          in API group "apps" in the namespace "arch-ns"',
reason: 'Forbidden',
details: [Object],
code: 403
}

Эта учетная запись пользователя принадлежит aws iam, и я использовал ее для создания тестового кластера с kubernetes, поэтому он является владельцем кластера. Любая операция в кластере, которую я делаю, я делаю, используя эту учетную запись, и она отлично работает (я могу создавать ресурсы и вносить изменения в них без каких-либо проблем, используя эту учетную запись).

Я создал дополнительную роль в этом пространстве имен и роли привязка для учетной записи пользователя aws, которую я использую, но это не решило проблему (и, вероятно, было излишним). Лямбда-функция имеет полные права доступа ко всем ресурсам на ecr и eks.

Есть ли у кого-нибудь похожие проблемы с такими исправлениями развертывания на eks с использованием лямбда-функции?

Answer 1

Вы можете проверить, есть ли у учетной записи службы RBA C для исправления развертывания в пространстве имен arch-ns

kubectl auth can-i patch deployment --as=system:serviceaccount:arch-user:default -n arch-ns

Если приведенная выше команда возвращает no, то добавьте необходимую роль и привязку роли к учетной записи службы .

Следует отметить, что его учетная запись службы default находится в пространстве имен arch-user, но пытается выполнить операцию в другом пространстве имен arch-ns

.