Может ли Lambda взять на себя роль IAM с условием когнитивного идентификатора пользователя?

Question

У нас есть динамо-таблица, которую мы используем для чувствительной к безопасности части нашего приложения с довольно строгими ограничениями на чтение (здесь мы стремимся к как можно более строгим). В идеале мы хотели бы ограничить доступ к этой таблице только теми строками, которые имеют совпадающие ведущие ключи когнито-userId (следуя этому подходу: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_rows.html). К сожалению, наши требования таковы, что лямбда-функция должна будет считывать значения от имени пользователя, чтобы впоследствии обработать и отправить значение пользователю (например, по почте).

Наша текущая настройка выглядит следующим образом: мы создали правило IAM с этим условием IAM с ведущим ключом и присоединили его к группе пользователей, которая включает всех пользователей, которые будут обращаться к этой таблице. Пока все хорошо, лямбда-функция извлекает правило из объекта контекста и принимает эту роль (через sts: acceptRole, вот так, они оба находятся в одной учетной записи: https://aws.amazon.com/premiumsupport/ центр знаний / когнито-пользователь-пул-группа /, https://aws.amazon.com/premiumsupport/knowledge-center/lambda-function-assume-iam-role/) И лямбда, и предполагаемая роль необходимые политики, так что это тоже работает должным образом. Тесты со статическими значениями, например следующие:

ForAllValues:StringEquals: 
  dynamodb:LeadingKeys: 
    - "SOMEKEY"

также подтвердите, что все необходимые учетные данные переданы, роль предполагается, все работает до этого момента.

К сожалению, он перестает работать при фактическом использовании ${cognito-identity.amazonaws.com:sub}в качестве идентификатора ведущего ключа, как с префиксом aws-region, так и без него. Отсюда мой вопрос, сталкивался ли кто-нибудь с этим раньше? Когда эта переменная заменяется правилом IAM? разрешается ли оно до того, как оно будет передано в лямбда-функцию (в этом случае мы ожидаем, что это значение будет заполнено) или оно будет заменено, пока лямбда обращается к динамо (в этом случае он не разрешается, поскольку лямбда, а не когнитивный пользователь берет на себя роль)? Есть ли способы смягчить это? Любая помощь будет принята с благодарностью

Answer 1

${ognito-identity.amazonaws.com:sub} ссылается на идентификатор идентификатора Cognito из пула идентификаторов. Поэтому, когда ваше приложение использует Identity Pool для получения временных учетных данных AWS, эти учетные данные будут содержать идентификатор пользователя. Если ваше приложение затем пытается получить строку из базы данных, пользователь может получить только свою строку, строку с идентификатором личности в качестве ведущего ключа.

Поэтому вместо того, чтобы принимать на себя роль IAM в лямбда-функции, используя sts accept role, вы можете передать токен Cognito ID в вашу Lambda, а затем передать токен ID в пул удостоверений для получения учетных данных. Эти учетные данные затем могут быть приняты SDK, и запросы, отправляемые Dynamo, будут использовать ${cognito-identity.amazonaws.com:sub}.

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

Надеюсь, это поможет.