Развертывание AWS Lambda из другого аккаунта

Question

У меня есть Lambda .jar, который я создаю из коробки Jenkins в учетной записи AWS ("Account_Bld"). После создания я копирую .jar в корзину S3 в другой учетной записи AWS ("Account_Dst") и пытаюсь обновить лямбда-запись в Account_Dst на основе недавно скопированного .jar в S3.

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

код функции лямбда-обновления aws - имя-функции arn: aws: лямбда: us-east-1: {Account_Dst_Id}: функция: {lambda_function_name} --zip-файл fileb: // {jar_file_relative_path} - регион сша-восток-1

Не удивительно, я получаю эту ошибку:

Произошла ошибка (AccessDeniedException) при вызове операции UpdateFunctionCode: пользователь: arn: aws: sts :: {Account_Bld_Id}: предполагаемая роль / {jenkins_ec2_role} / {jenkins_ec2_instance_id} не авторизован для выполнения: lambda: UpdateFunctionCode для ресурса : arn: aws: lambda: us-east-1: {Account_Dst_Id}: function: {lambda_function_name}

Я дал права jenkins_ec2_role для обновления Lambda в другой учетной записи, но имеет смысл, что мне нужно будет ответить взаимностью этим правам где-то в Account_Dst - при условии, что есть простое решение этой проблемы.

Теперь возможные решения. Я мог бы взять на себя роль в Account_Dst, которая имеет правильные права, и обновить Lambda, но это больше хлопот при настройке, чем оно стоит мне сейчас. Я видел некоторые предложения Google, чтобы я мог использовать CodePipeline, но, очевидно, я использую Jenkins, так что это тоже не кажется хорошим решением.

Итак, вопрос в том, есть ли здесь простое решение, которого мне не хватает?

Answer 1

Предоставление разрешений в Account_Bld для доступа к Account_Dst недостаточно для получения доступа к другой учетной записи. Это хорошо, потому что вы не хотели бы, чтобы люди предоставляли себе доступ к учетным записям других людей.

Целевой аккаунт должен принять входящий запрос. Метод зависит от сервиса. Например, Amazon S3 может создать политику Bucket, чтобы разрешить доступ из других учетных записей, как и Amazon SQS.

Однако в Lambda нет такой концепции для настройки входящих запросов от других учетных записей. Просто нигде нельзя настроить разрешение update-function-code с другой учетной записи.

Поэтому вам нужно будет сделать то, что вы предложили:

• Создание пользователя IAM или роли IAM в Account_Dst
• Используйте учетные данные от пользователя Account_Dst IAM (самый простой) или используйте существующие учетные данные Account_Bld, чтобы принять роль в Account_Dst (еще несколько строк кода)
• Звоните update-function-code, используя эти учетные данные