基于密钥获取Cognito临时AWS凭证的技术方案咨询

关于API Gateway自定义授权器的误解纠正 #

你对自定义授权器的理解有偏差：它不仅能控制API端点的访问，还可以通过以下方式让后端获取认证主体信息并访问其他AWS资源：

• 验证凭证后返回包含用户声明的IAM临时策略，API Gateway会用这个策略生成临时凭证，后端服务可直接使用该凭证访问资源。
• 将用户声明（如用户ID、标签）注入到请求上下文中，后端服务读取上下文后，基于这些信息调用AWS资源时做权限过滤。

核心问题解答：API密钥能否实现类Cognito的主体认证？ #

可以，但需要额外的密钥管理逻辑：

• 你需要维护一个密钥与用户信息的映射存储（如DynamoDB），记录每个API密钥关联的用户ID、标签、权限范围。
• 自定义授权器验证API密钥后，从存储中查询用户信息，生成包含用户声明的IAM策略或上下文，传递给后端。
• 后端基于这些声明关联对应的IAM角色或过滤资源访问。

但这种方案存在密钥生命周期管理（轮换、撤销）的额外成本，且密钥本身是静态凭证，相比AWS原生的临时凭证方案，安全风险更高。

更优方案推荐 #

方案1：IAM角色+信任策略+用户属性关联 #

这是最符合AWS安全最佳实践的方案：

• 为每个调度任务创建专用IAM角色，信任策略允许调度服务（如EventBridge、Step Functions）调用sts:AssumeRole。
• 在角色的权限策略中，通过条件键绑定原用户属性，例如：

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::my-bucket/*",
        "Condition": {
          "StringEquals": {
            "s3:ResourceTag/OwnerUserID": "${aws:PrincipalTag/OwnerUserID}"
          }
        }
      }
    ]
  }
  

• 调度任务时，将原用户的ID、标签等信息作为角色标签或任务参数存储，任务执行时Assume该角色，自动继承基于用户属性的权限控制。

方案2：Cognito身份池自定义身份提供商 #

复用Cognito的身份体系，避免自行管理凭证：

• 将调度任务的唯一标识作为自定义身份，在Cognito身份池中关联原用户的声明（如用户ID、标签）。
• 任务执行时，用该自定义身份调用Cognito身份池的凭证获取接口，得到包含用户声明的临时IAM凭证。
• 基于凭证中的声明，通过IAM角色的信任策略或权限策略限制资源访问。

方案3：改进型自定义授权器+API密钥（适合必须用密钥的场景） #

如果坚持使用API密钥，需优化安全与管理流程：

• 用Secrets Manager存储API密钥，而非明文存储，定期自动轮换密钥。
• 自定义授权器验证密钥时，从Secrets Manager和用户信息存储中查询关联的用户声明，生成精细的IAM策略。
• 后端服务通过API Gateway传递的凭证或上下文，基于用户声明访问资源。

总结 #

优先选择方案1或方案2，它们基于AWS原生IAM和Cognito体系，无需自行管理静态凭证，权限控制更灵活且符合安全最佳实践。若必须使用API密钥，方案3可满足需求，但需承担额外的密钥管理成本。

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