iam:PassRole 噩梦——我再也回不来的三周时光

2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家 

让我讲讲我生命中再也无法挽回的三周故事。

我们当时正在亚马逊云科技 Bedrock 上构建一个人工智能代理——一个用于管理基础设施生命周期操作的自主系统。该代理在我们的沙盒环境中运行完美。是时候将其部署到企业环境了。应该只需要一个下午，对吧？

结果却花了三周时间。

背景设置

要部署一个 Bedrock 代理，您需要附加一个身份和访问管理角色——即代理在调用基础模型时所承担的执行角色。这需要 iam:PassRole 权限。听起来很简单。

在我们的企业环境中，每个开发者角色都附加了一个托管策略。我们称之为 OrgDenyEscalation。该策略包含对 iam:PassRole 的显式拒绝：

{
    "Effect": "Deny",
    "Action": [
        "iam:PassRole",
        "iam:CreateRole",
        "iam:AttachRolePolicy",
        "iam:DeleteRole"
    ],
    "Resource": "*"
}

关于身份和访问管理评估的关键点在于：显式拒绝始终优先。 无论您是否拥有 AdministratorAccess（管理员访问权限）都无关紧要。即使您创建了一个允许 iam:PassRole 的自定义策略也无关紧要。附加到您身份上的任何策略中的显式拒绝都会覆盖所有允许操作，绝无例外。

因此，我们无法通过命令行界面部署该代理。aws bedrock-agent create-agent 命令返回了以下错误：

AccessDeniedException: User is not authorized to perform iam:PassRole

我们花了三天时间试图找出原因。我们阅读了每一份身份和访问管理文档、每一篇博客文章以及每一个堆栈溢出论坛的回答。我们添加了更广泛的权限，尝试了不同的角色，但没有任何方法奏效。

无人提及的根本原因

企业级身份和访问管理并不是“不断添加权限直到能运行为止”。它是一个具有多层结构的策略评估链：

请求 -> 服务控制策略（组织层级）
       -> 权限边界（账户层级）
       -> 托管策略（角色/用户层级）
       -> 内联策略（角色/用户层级）
       -> 资源策略（存储桶/队列等层级）

我们的组织拥有：

1. 服务控制策略：组织层级的限制。不可更改。
2. 权限边界：账户层级对角色最大权限的限制。
3. 托管策略：附加到所有开发者角色的全企业范围策略。这些策略拒绝危险操作（iam:PassRole、iam:CreateRole）。您无法修改或解除附加它们。
4. 您的自定义策略：仅对未被第 1-3 层显式拒绝的操作有效。

我们一直在对抗