如何在IAM策略变量中访问Cognito用户池自定义属性实现多租户？

看起来你已经搭好了基础的多租户框架，但卡在了如何用用户的custom:org_id属性代替硬编码的组织ID来控制DynamoDB行访问上。我来帮你梳理下问题原因和可行的解决方案：

为什么直接引用Cognito用户池属性会失败？ #

IAM策略无法直接读取Cognito用户池的自定义属性，因为IAM角色的会话是由Cognito联邦身份池（Federated Identities）生成的，用户池的属性不会自动传递到角色会话中。你之前写的${cognito-idp.{region}.amazonaws.com/{poolID}:attr[custom:org_id]}这种语法，只有在特定的信任策略场景下才有效，不能直接用在资源访问的Condition里。

正确的实现步骤：把用户属性映射到角色会话 #

要让IAM策略能拿到用户的custom:org_id，需要先通过身份池把这个属性传递到角色的会话变量中，具体操作如下：

1. 在Cognito身份池中配置属性映射 #

• 打开AWS控制台的Cognito身份池页面，找到你的身份池，进入**“编辑身份池”**
• 滚动到**“认证角色选择”部分，点击“属性映射”**
• 点击**“添加映射”**，在“用户池属性”中选择custom:org_id，在“身份池属性”中选择https://aws.amazon.com/userinfo#custom:org_id（或者直接映射到会话标签org_id）
• 保存配置，确保身份池会把用户的custom:org_id属性注入到角色的会话上下文里

2. 修改IAM策略，引用会话变量 #

现在你可以在IAM策略中引用角色会话中的org_id属性了，有两种常用的引用方式：

方式一：使用会话标签（推荐）

如果映射时选择了会话标签，策略可以这样写：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowTenantSpecificAccess",
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:BatchGetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem",
        "dynamodb:Query" // 现在可以加回来了
      ],
      "Resource": "arn:aws:dynamodb:{region}:{account-id}:table/*",
      "Condition": {
        "StringEquals": {
          "dynamodb:LeadingKeys": "${aws:PrincipalTag/org_id}"
        }
      }
    }
  ]
}

方式二：使用身份上下文变量

如果映射到了https://aws.amazon.com/userinfo#custom:org_id，可以用上下文变量引用：

"Condition": {
  "StringEquals": {
    "dynamodb:LeadingKeys": "${context.identity.custom:org_id}"
  }
}

3. 关于dynamodb:Query和dynamodb:LeadingKeys的问题 #

文档里说的没错，dynamodb:Query确实支持dynamodb:LeadingKeys条件，但要注意：

• Query操作的KeyConditionExpression必须是针对分区键（也就是你说的LeadingKey）的查询
• 确保IAM策略中明确包含了dynamodb:Query权限
• 如果你用的是ForAnyValue:StringEquals，其实对于单个org_id来说，用StringEquals就足够了

其他多租户实现方案建议 #

如果上述方式还是有问题，或者你需要更灵活的控制，可以考虑这些方案：

方案一：基于Cognito组的租户隔离 #

给每个租户创建一个Cognito组，组关联的IAM角色预设好该租户的org_id标签（在角色的标签里添加org_id:xxx），然后IAM策略通过aws:ResourceTag/org_id或者aws:PrincipalTag/org_id来控制访问。这种方式适合租户数量较少、租户信息相对固定的场景。

方案二：使用DynamoDB细粒度访问控制（FGAC）结合Lambda授权 #

如果需要更复杂的访问规则（比如跨租户的特殊权限），可以在API Gateway或者AppSync中使用Lambda授权器，先获取用户的custom:org_id，再动态生成允许访问的DynamoDB行范围，或者直接在Lambda中做权限校验。

排查小技巧 #

• 可以通过调用AWS CLI的aws sts get-caller-identity或者在前端用cognito-identity-js获取凭证后，查看会话中的标签/上下文变量，确认org_id是否已经正确传递
• 检查用户的custom:org_id属性是否在Cognito用户池中正确设置，并且用户登录后能获取到该属性
• 暂时放宽权限（比如去掉Condition），确认基础的DynamoDB访问是否正常，再逐步添加条件排查问题

内容的提问来源于stack exchange，提问作者kevex91