AWS Secrets Manager 指定主体权限未生效 如何配置仅特定主体访问

你对权限传递的假设存在根本性错误 #

你的假设完全不成立，核心是两个认知偏差：

• 你当前策略里写的Principal不是xxx角色的固定ARN，而是两次动态生成的临时会话ARN（即assumed-role路径下带具体用户名的会话标识）。这类ARN是角色被代换时临时生成的，最长12小时就会失效，根本不具备长期授权的能力，更不可能实现“xxx角色被授权，所有会话下的用户自动获得权限”的传递逻辑。
• 你误解了IAM策略的评估优先级：资源策略中的Allow语句只是权限的来源之一，根本不是拦截未授权用户的白名单。IAM的默认规则是无策略即拒绝，但只要任意策略来源（身份策略、资源策略、托管权限策略、SCP等）给请求身份授予了对应操作的Allow，且没有任何来源的显式Deny，请求就会被放行。其他用户能成功执行put-secret-value，本质是这些用户本身就从自己绑定的身份权限中拿到了Secrets Manager的操作许可，你当前只写了Allow、没有任何拦截逻辑的资源策略，根本无法抵消其他来源的权限授权。

正确实现“仅指定人员可访问、拦截所有其他用户”的配置方法 #

要实现严格的白名单访问控制，不能只靠写Allow规则，必须搭配优先级最高的显式Deny规则，两步缺一不可：

1. 修正授权规则的Principal字段：把原来写的临时会话ARN替换为固定的实体ARN，包括需要放行的IAM用户ARN、目标角色的固定ARN、身份提供商对应的用户身份ARN，这类ARN不会随会话生命周期失效，能实现长期稳定的授权。
2. 新增基于NotPrincipal的全局显式Deny规则：利用IAM中“显式Deny优先级最高”的规则，把所有不在白名单内的身份全部拦截。注意必须把账号根用户排除在Deny范围外，避免锁死管理员后续调整权限的通道。

参考正确策略示例 #

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowTrustedIdentities",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::SLJFLSDKFJLSJDKF:role/xxx",
          "arn:aws:iam::SLJFLSDKFJLSJDKF:user/指定放行的用户A"
        ]
      },
      "Action": "secretsmanager:*",
      "Resource": "*"
    },
    {
      "Sid": "DenyAllOtherAccess",
      "Effect": "Deny",
      "NotPrincipal": {
        "AWS": [
          "arn:aws:iam::SLJFLSDKFJLSJDKF:role/xxx",
          "arn:aws:iam::SLJFLSDKFJLSJDKF:user/指定放行的用户A",
          "arn:aws:iam::SLJFLSDKFJLSJDKF:root"
        ]
      },
      "Action": "secretsmanager:*",
      "Resource": "*"
    }
  ]
}

配置注意事项 #

• 永久不要把临时assumed-role会话ARN作为长期授权的Principal对象，这类标识有效期极短，配置完成后很快就会失效。
• 写NotPrincipal的Deny规则时，必须把账号根ARN加入例外列表，否则一旦规则生效，所有管理员包括你自己都无法修改该资源的后续策略，只能通过官方支持渠道解锁。
• 显式Deny不受其他Allow规则的影响，哪怕其他用户从自身身份策略拿到了完整的Secrets Manager权限，只要被这条Deny规则命中，所有请求都会被直接拦截。

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