Serverless项目中Assumed Role无法执行secretsmanager:GetSecretValue问题求解

关于STS Assumed Role的说明 #

Lambda运行时会自动通过STS服务Assume你为Lambda配置的执行角色，生成短期有效的临时访问凭证，报错里的arn:aws:sts::{accountId}:assumed-role/xxx/xxx是该临时凭证对应的身份标识，属于Lambda的正常运行机制，不是问题原因。

问题原因和修复方案 #

原因1：密钥使用自定义KMS CMK加密，缺少KMS解密权限 #

这是该场景下最常见的问题原因。如果你的Secret没有使用Secrets Manager默认的托管密钥（别名aws/secretsmanager），而是使用了自行创建的KMS客户托管密钥（CMK）加密，仅授予secretsmanager:GetSecretValue权限不足以完成密钥读取，还需要为Lambda执行角色添加kms:Decrypt权限，对应资源为该KMS密钥的ARN。
修复方法：在原有IAM Policy的Statement数组中添加如下配置：

{
    "Effect": "Allow",
    "Action": [
        "kms:Decrypt"
    ],
    "Resource": "arn:aws:kms:eu-west-1:<你的AWS账号ID>:key/<你的KMS密钥ID>"
}

验证阶段可以临时将Resource设置为*确认是否是该问题，确认后再收紧权限范围。

原因2：SecretId解析错误 #

你代码中传入的是Secret的友好名称my_secret_name，如果该Secret不在当前账号下，或是存在多版本/名称相近的密钥，可能会导致ARN解析不匹配。建议直接传入完整的Secret ARN调用，避免解析错误：
修改代码中的调用参数：

const secret = await sm.getSecretValue({
  SecretId: 'arn:aws:secretsmanager:eu-west-1:<你的AWS账号ID>:secret:my_secret_name-<密钥实际的随机后缀>'
})

你可以登录Secrets Manager控制台，直接复制对应密钥的完整ARN填入代码测试。

原因3：上层权限限制 #

如果你的账号归属AWS Organizations组织，或是Lambda执行角色配置了权限边界（Permission Boundary），即使角色本身的访问策略允许操作，也可能被上层的限制规则拦截。你可以联系账号管理员确认是否存在相关的SCP（服务控制策略）或是权限边界限制。

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