调用GenerateServiceLastAccessedDetails遇AccessDenied，已附SecurityAudit权限仍报错

这绝对不是AWS的bug，这类权限报错几乎都是因为IAM权限模型的细节没考虑到，我来帮你拆解可能的原因和排查方向：

1. 权限边界（Permission Boundary）的限制 #

虽然你附加的SecurityAudit策略里资源范围是*，但如果你的<assumed_role>本身设置了权限边界，这个边界会优先限制你的可执行操作。权限边界是一种最大权限限制，即使附加策略允许某个操作，只要边界策略不允许对目标<role_arn>执行iam:GenerateServiceLastAccessedDetails，就会触发AccessDenied。

你可以通过以下命令检查该角色的权限边界：

aws iam get-role --role-name <assumed_role_name> --query 'Role.PermissionsBoundary'

如果返回了边界策略ARN，需要确认该策略是否包含对目标角色ARN的iam:GenerateServiceLastAccessedDetails权限。

2. 会话策略（Session Policy）的缩小限制 #

当你扮演<assumed_role>时，如果发起扮演请求时指定了会话策略，这个策略会进一步缩小你的权限范围——哪怕SecurityAudit策略允许所有资源，会话策略也可能会排除对目标<role_arn>的操作权限。

你可以重新扮演角色时不指定会话策略再测试一次，或者通过IAM Access Advisor查看当前会话的有效权限。

3. 权限模拟验证 #

最直接的方法是用IAM权限模拟工具验证你的策略是否真的允许对目标角色执行该操作：

aws iam simulate-custom-policy \
  --policy-input-list '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":["iam:GenerateServiceLastAccessedDetails","iam:Get*","iam:List*"],"Resource":"*"}]}' \
  --action-names iam:GenerateServiceLastAccessedDetails \
  --resource-arns <role_arn>

如果模拟结果返回Allowed，那问题大概率出在权限边界或会话策略；如果返回Denied，那可能你的策略存在隐性条件限制（比如区域、标签等）。

4. 目标角色的相关权限检查 #

虽然你的策略包含iam:Get*，但还是要确认你是否能正常调用aws iam get-role --role-name <target_role_name>——如果这个操作也报错，那可能是其他权限限制导致的连锁问题，但根据你的描述，这个应该是正常的。

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