IAM角色配置权限后仍无法访问AWS Secrets Manager密钥求助

问题场景 #

拥有ARN为arn:aws:secretsmanager:us-east-1:022528294191:secret:prjdevrdsauroraSecretD01269-itTuR5vpdyr5-ddd11d的SecretsManager密钥，以及名为prj-dev-prjdevlambdaroleEFBCDBFF-OwcoRUhPiEZI的IAM角色，角色已附加如下内联策略：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "arn:aws:secretsmanager:us-east-1:022528294191:secret:prjdevrdsauroraSecretD01269-itTuR5vpdyr5-ddd11d",
            "Effect": "Allow"
        }
    ]
}

通过aws sts assume-role获取角色凭证并配置到AWS CLI后，执行命令：

aws secretsmanager get-secret-value --secret-id arn:aws:secretsmanager:us-east-1:022528294191:secret:prjdevrdsauroraSecretD01269-itTuR5vpdyr5-ddd11d

收到AccessDenied错误：

An error occurred (AccessDeniedException) when calling the GetSecretValue operation:
 User: arn:aws:sts::022528294191:assumed-role/prj-dev-prjdevlambdaroleEFBCDBFF-OwcoRUhPiEZI/testSession 
is not authorized to perform: secretsmanager:GetSecretValue on resource: arn:aws:secretsmanager:us-east-1:022528294191:secret:prjdevrdsauroraSecretD01269-itTuR5vpdyr5-ddd11d 
because no identity-based policy allows the secretsmanager:GetSecretValue action

已完成排查：

• 密钥未配置任何资源型限制策略
• CDK生成的角色和权限无拼写错误
• 角色未设置权限边界
• 所有操作在同一AWS账户内执行
• 其他实体扮演该角色时均出现相同问题

补充背景信息：

• 密钥由aws-cdk-lib/aws-rds库的new ServerlessCluster自动创建
• 角色由aws-cdk-lib/aws-iam库的new Role创建，权限通过密钥对象的grantRead()方法生成

后续异常现象：

1. 手动创建新密钥并添加到角色内联策略后，仍无法访问，确认问题根源在角色本身
2. 为角色附加SecretsManagerReadWrite托管策略后，可正常访问两个密钥；移除托管策略恢复原配置后，角色竟能正常访问原目标密钥，但无法访问新密钥，问题自行恢复但原因不明

可能的原因分析 #

1. IAM策略传播延迟 #

IAM策略（尤其是内联策略）的变更不会实时同步到所有AWS服务节点，通常需要5-10分钟的缓存生效时间。如果是CDK刚部署完成就进行测试，可能策略还未完全同步。

2. SecretsManager ARN的特殊匹配逻辑 #

SecretsManager的ARN存在两种形式：带随机后缀的完整ARN和仅包含密钥前缀的简化ARN。虽然策略中使用了正确的完整ARN，但AWS内部权限校验偶尔会出现后缀匹配的临时异常。

3. CDK grantRead()的隐式条件限制 #

使用CDK的grantRead()方法时，框架可能自动添加了未显式展示的条件限制（比如aws:ResourceAccount），虽然控制台显示的策略内容正确，但实际生效的策略可能包含隐藏条件，导致权限校验不通过。

4. 临时凭证缓存旧权限 #

通过aws sts assume-role获取的临时凭证默认有效期为1小时，若在策略更新前已获取凭证，旧凭证会保持原有权限状态，直到过期。测试时需确保使用最新生成的临时凭证。

5. AWS服务内部数据同步异常 #

附加托管策略再移除后恢复正常的现象，大概率是AWS服务内部的权限数据同步出现异常。附加托管策略触发了角色权限的强制刷新，修复了之前的同步延迟或数据不一致问题。

验证与解决步骤 #

1. 等待策略完全同步：若刚部署完CDK，等待10-15分钟后再测试，避免传播延迟导致的权限不生效问题。
2. 使用IAM策略模拟器校验：在AWS控制台进入该IAM角色页面，使用「策略模拟器」模拟secretsmanager:GetSecretValue操作，选择目标密钥ARN，查看详细的权限判定结果，确认是否存在隐藏的拒绝条件。
3. 重新生成临时凭证：执行aws sts assume-role重新获取角色凭证，确保使用的是最新的权限配置。
4. 显式添加账户匹配条件：若怀疑CDK生成的策略存在隐藏限制，可手动修改内联策略，添加aws:ResourceAccount条件明确指定账户：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue"
            ],
            "Resource": "arn:aws:secretsmanager:us-east-1:022528294191:secret:prjdevrdsauroraSecretD01269-itTuR5vpdyr5-ddd11d",
            "Effect": "Allow",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceAccount": "022528294191"
                }
            }
        }
    ]
}

5. 强制刷新角色权限：若遇到类似的同步异常，可通过附加再移除一个低权限托管策略（如SecretsManagerReadOnlyAccess），触发角色权限的重新同步。

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