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

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

Наша текущая настройка выглядит следующим образом: мы создали правило IAM с этим условием IAM с ведущим ключом и присоединили его к группе пользователей, которая включает всех пользователей, которые будут обращаться к этой таблице. Пока все хорошо, лямбда-функция извлекает правило из объекта контекста и принимает эту роль (через sts: acceptRole, вот так, они оба находятся в одной учетной записи: https://aws.amazon).com/premiumsupport/knowledge-center/ognito-user-pool-group/, 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? разрешается ли оно до того, как оно будет передано в лямбда-функцию (в этом случае мы ожидаем, что это значение будет заполнено), или оно заменяется, когда лямбда обращается к динамо (в этом случае он не разрешается, так как лямбда, а не когнитивный пользователь берет на себя роль)? Есть ли способы смягчить это? Любая помощь будет принята с благодарностью


person Wassily    schedule 23.06.2020    source источник


Ответы (1)


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

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

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

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

person callo    schedule 23.06.2020
comment
большое спасибо! чтобы токен Cognito ID был токеном, который пользователь получает при входе в систему? или это идентификатор, который они получают из пула идентификаторов? Можно ли по-прежнему следовать этому подходу, используя Cognito в качестве авторизатора для Api Gateway, или в этом случае клиенту придется передавать identityId отдельно? (хотя я могу здесь кое-что перепутать) - person Wassily; 23.06.2020
comment
Таким образом, пользователь входит в UserPool и получает три токена: ID, доступ, refrsh. Этот токен идентификатора необходимо использовать для получения учетных данных из пула удостоверений. Использование этих учетных данных для совершения звонков позволит IAM проверить $ {cognito-identity.amazonaws.com:sub}. Идентификационный идентификатор должен быть ведущим ключом, и этот идентификатор будет получен при первом обмене пользователем токена идентификатора с пулом идентификаторов. Другой вариант для вас может заключаться в том, что клиент может напрямую получать кредиты AWS из Identity Pool и звонить в Dynamo. - person callo; 23.06.2020
comment
еще раз большое спасибо! В итоге я последовал вашему подходу, получил учетные данные из токена идентификатора Cognito, и, похоже, это сработало! - хотя, к сожалению, кажется, что пользователь не получает требуемых разрешений, неужели это cognito-identity.amazonaws.com:sub identityId пользователя, срок действия которого истекает через час? - person Wassily; 25.06.2020
comment
когда вы обмениваете свой токен на временные учетные данные, Cognito Identity Pool предоставит вам идентификатор Identity ID. Этот идентификатор личности является уникальным идентификатором пула идентификации для данного пользователя. Если вы обменяете свой токен на новые учетные данные позже, вам будет предоставлен тот же идентификатор личности. Get ID возвращает идентификатор Identity ID, если на устройстве он не сохранен docs.aws.amazon.com/cognito/latest/developerguide/ Я бы посоветовал посмотреть это руководство по Amplify docs.amplify.aws/lib/storage/getting-started/q/platform/ - person callo; 25.06.2020
comment
Возможно, вы все же сможете помочь - я наткнулся на этот пост, когда искал решение своей проблемы. У меня есть своего рода мультитенантное приложение (однако многие арендаторы могут быть однопользовательскими). OrganisationId будет идентификатором группы Congito и ключом раздела в таблице DynamoDB. Как принять на себя роль пользователя в моих лямбдах, чтобы пользователь мог получить доступ к данным своей организации? - person Marek Urbanowicz; 02.03.2021