AWS Lambda: даже после того, как STS: AssumeRole был успешным, лямбда-функция все еще использует старую роль IAM

Question

Я создал новую роль IAM, которая имеет доступ (сканирование / запрос) к определенным таблицам DynamoDb.

Я пытаюсь использовать вызов API-функции STS Assume Role из моей лямбда-функции, чтобы лямбда-функция получила доступ к конкретным таблицам Dynamo Db.

Успешный вызов роли "Роль" выполнен, я получил идентификатор роли, AccesskeyId, секретный ключ доступа и токен сеанса.

Когда я выполняю вызов из своей лямбда-функции для доступа к БД Dynamo, я получаю сообщение об ошибке

AccessDeniedException: пользователь: ARN: AWS: ГНС ::>: предполагается, роль / ОТА-DEV-нас-восток-1-lambdaRole / не авторизован для выполнения: Dynamodb: сканирование на ресурс: ARN: AWS: dynamodb: нас-восток-1>: таблица / <>

У меня такой вопрос, что даже после успешного вызова Role Assume в функции Lambda, почему функция lambda все еще использовала более старую роль для доступа к базе данных Dynamo?

Я ожидал, что функция Lambda возьмет на себя новую роль, но, судя по журналам, она использует еще более старую роль.

Похоже, мне не хватает промежуточных шагов.

Answer 1

Вызов STS AssumeRole, в зависимости от того, как вы его инициируете, не обновляет автоматически учетные данные в глобальном объекте AWS.config SDK.

Вам необходимо получить ключ доступа, сеансовый ключ и сеанстокен, возвращаемый AssumeRole и передаваемый в ваш глобальный объект SDK с учетными данными AWS.

Точный код будет зависеть от используемого вами языка программирования, вот документация для Python Boto3

https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html

Кстати, мне интересно, почему вы не предоставляете постоянный доступ к своей таблице DynamoDB в роли выполнения Lambda.Это должно ограничить охват функции и предоставить детальный контроль доступа во время выполнения, основанный на личности вызывающего абонента?