アプリケーションのセキュリティが重要な部分に使用する dynamo テーブルがあり、かなり厳格な読み取りアクセス制限があります (ここでは可能な限り厳格にすることを目指しています)。理想的には、そのテーブルへのアクセスを、一致する cognito-userId 先行キーを持つ行のみに制限したいと考えています (このアプローチ: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_rows.htmlに従います)。残念ながら、私たちの要件は、ラムダ関数が後で値を処理してユーザーに送信するために、ユーザーに代わって値を読み取る必要があるというものです (たとえば、メールを介して)。
現在のセットアップは次のようになっています: その先行キー IAM 条件を使用して IAM ルールを作成し、そのテーブルにアクセスするすべてのユーザーを含むユーザー グループにアタッチしました。これまでのところ、ラムダ関数はコンテキスト オブジェクトからルールをフェッチし、その役割を引き受けます (sts:assumeRole を介して、同じように、両方とも同じアカウントにあります: https://aws.amazon.com/premiumsupport/ knowledge-center/cognito-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 ルールに置き換えられるのはいつですか? ラムダ関数に渡される前に解決されているか（この場合、その値が入力されることが期待されます）、またはラムダがdynamoにアクセスしている間に置換されていますか（この場合、コグニトユーザーではなくラムダであるため解決されていません）役割を引き受けます）？これを軽減する方法はありますか？どんな助けでも大歓迎です