大家好,今天我们来解决一个非常具体的实战问题:如何让 IAM Identity Center 中创建的用户真正获得 AWS 账户的操作权限,从而取代老旧的 IAM 用户管理模式?
如果我们盯着用户详情页,想找一个“附加角色”的按钮,那我们可能会失望。因为 IAM Identity Center 的魔法发生在更高一个层级。
核心理念:解耦“人”与“权限”
传统 IAM 用户模式下,“人”(用户)和“权限”(策略)是紧密绑定的。而在 IAM Identity Center 中,这个绑定被优雅地解开了,中间引入了两个关键概念:权限集 (Permission Sets) 和 分配 (Assignments)。
正确的流程是这样的:
- 用户和组 (Users & Groups):定义“谁是这个人”。我们已经完成了这一步,
dave
是一个人,他属于dev
这个组。 - 权限集 (Permission Sets):定义“可以做什么”。这就是 IAM Identity Center 里的“角色蓝图”。我们可以在这里创建一系列权限模板,比如 “数据库管理员权限”、“开发者只读权限”或“EC2完全访问权限”。
- 分配 (Assignments):将“谁”和“可以做什么”在具体的“哪个地方”(AWS 账户)连接起来。
实战步骤:三步完成授权
现在,让我们来完成从 dave
到实际权限的最后几步。
第 1 步:创建权限集 (Permission Set) - 我们的“权限模板”
这是最关键的一步。权限集定义了一套具体的权限,它在被分配到某个 AWS 账户时,IAM Identity Center 会自动在该账户中为我们创建一个对应的 IAM 角色。
- 在 IAM Identity Center 控制台的左侧导航栏中,找到并点击 “权限集” (Permission sets)。
- 点击 “创建权限集” (Create permission set) 按钮。
- 我们有三个选择:
- 使用 AWS 托管策略:最简单的方式。比如,我们可以选择
AdministratorAccess
或PowerUserAccess
策略来创建一个“管理员权限集”。 - 复制现有权限集:如果我们已经有一个模板,可以复制并微调。
- 自定义权限集:最灵活的方式。我们可以像创建普通 IAM 角色一样,内联编写 JSON 策略,或者附加多个 AWS 托管策略和自定义策略。
- 使用 AWS 托管策略:最简单的方式。比如,我们可以选择
实用建议: 为我们的 dev
组创建一个名为 DeveloperAccess
的权限集。在自定义权限时,我们可以附加 AmazonEC2FullAccess
和 AmazonS3ReadOnlyAccess
策略,以满足开发者的常见需求。
第 2 步:分配对 AWS 账户的访问权限 - 连接一切
现在,我们有了用户组 (dev
) 和权限模板 (DeveloperAccess
),是时候把它们应用到具体的 AWS 账户上了。
- 在 IAM Identity Center 控制台的左侧导航栏中,点击 “AWS 账户” (AWS accounts)。这里会列出我们 AWS Organization 中的所有账户。
- 勾选我们希望
dev
组能够访问的一个或多个 AWS 账户(例如,dev-account
)。 - 点击 “分配用户或组” (Assign users or groups) 按钮。
- 在“用户和组”页签下,选择
dev
组,然后点击“下一步”。 - 在“权限集”页签下,勾选我们刚刚创建的
DeveloperAccess
权限集,然后点击“下一步”。 - 检查我们的分配(将
dev
组以DeveloperAccess
权限分配到dev-account
),然后点击 “提交”。
幕后发生了什么? 当我们点击提交后,IAM Identity Center 会自动在 dev-account
这个 AWS 账户中,创建一个名为 AWSReservedSSO_DeveloperAccess_xxxxxxxx
的 IAM 角色。这个角色的权限策略就是我们在权限集中定义的,并且其信任策略被精确地设置为信任我们的 IAM Identity Center 实例。
第 3 步:用户登录并使用权限
现在,用户 dave
的授权之旅已经完成!他可以:
- 访问我们公司的专属 AWS 访问门户 URL(形如
d-xxxxxxxxxx.awsapps.com/start
)。 - 使用他的用户名
dave
和密码登录。 - 登录后,他会看到一个清晰的卡片,上面写着
dev-account
。 - 点击这个账户,如果他被分配了多个权限集(角色),他可以选择以
DeveloperAccess
的身份登录。 - 点击后,他就可以选择是通过“管理控制台”还是“命令行/API”获取访问凭证。选择控制台会直接将他无缝重定向到
dev-account
的 AWS 控制台,并已承担好对应的角色,无需再次输入密码。
结论:拥抱新范式
总结一下,我们不需要在用户 dave
的页面上寻找关联角色的地方。正确的做法是:
- 定义“权限蓝图” -> 创建
Permission Set
。 - 连接“人、权限、地点” -> 在
AWS Accounts
页面,将Group
和Permission Set
分配给目标账户。
这种方式极大地简化了多账户环境下的权限管理。当我们有新的开发者加入时,只需将他加入 dev
组,他就自动获得了所有已分配给该组的账户和权限,安全、高效且易于审计。这正是 IAM Identity Center 取代传统 IAM 用户的核心优势所在。