揭秘 IAM Identity Center 的两种模式：为什么我的控制台没有“权限集”？IAM Identity Ce

大家好，今天我们来破解一个 IAM Identity Center 的“谜题”：为什么有时候登录进去，控制台功能齐全，有用户、组、AWS账户、权限集等所有选项；而有时候，却像下面这位朋友遇到的情况一样，只有用户、组和应用，关键的“权限集”和“AWS账户分配”功能消失了？

答案是，我们可能正在体验 IAM Identity Center 的两种不同“工作模式”之一。这并非 Bug，而是一种特性的体现，其根源在于它的预置方式 (Provisioning Method) 和我们在 AWS Organizations 中的角色。

这是 IAM Identity Center 最经典、最强大的使用模式。

谁来管理： 通常在 AWS Organizations 的管理账户（Management Account） 或被授权的 委托管理员账户（Delegated Admin Account） 中启用和配置。
控制台长什么样： 功能齐全！我们会看到包括 “AWS 账户” (AWS accounts) 和 “权限集” (Permission sets) 在内的所有导航选项。
核心目标： 集中管理对组织内所有或部分 AWS 账户的访问权限。管理员在这里创建用户/组，定义权限集（即权限模板），然后将它们“分配”给不同的 AWS 账户。这是实现跨账户单点登录（SSO）和集中化权限管理的核心。

可以把这个模式想象成公司的**“全球总部安保中心”**。它有权决定哪个部门（组）的员工（用户）可以进入哪栋大楼（AWS 账户），并授予他们不同的门禁卡权限（权限集）。

这就是子账号所处的情况。

谁来管理： 可以在任何一个 AWS 成员账户 (Member Account) 中独立配置。
控制台长什么样： 功能精简。我们只会看到 “用户” (Users)、“组” (Groups) 和 “应用程序” (Applications)。没有管理多账户权限的选项，因为它的职责范围就不是这个。
核心目标： 将单个应用程序（可以是自定义应用，也可以是 AWS 托管的应用如 Amazon Managed Grafana, Amazon Redshift 等）与一个身份源（如 Okta, Azure AD, 或者 IAM Identity Center 自身的目录）集成，以实现该应用的单点登录。

可以把这个模式想象成公司某栋大楼里的一个**“独立门禁系统”**。它的任务就是管理能进入这个特定系统（我们的应用）的人员名单，而不管这些人是否能进入公司其他的大楼。

现在我们已经明白了原因，接下来的行动就很清晰了：

确认我们的位置： 我们当前所在的 AWS 账户是一个成员账户。我们看到的 IAM Identity Center 实例是为该账户内的某个特定应用服务的，而不是整个组织的中央身份枢纽。
找到“总司令部”： 如果我们的目标是获取对多个 AWS 账户（例如开发账户、测试账户）的访问权限，我们需要联系我们的云管理员或IT部门。
向管理员请求权限： 我们需要告诉管理员：
- 我们的用户名是 dave。
- 我们属于 dev 组。
- 请在组织的中央 IAM Identity Center 实例中，为 dev 组分配访问相应 AWS 账户的权限集。

管理员会在他们的“全功能”控制台里，轻松地将 dev 组与 DeveloperAccess 权限集关联，并授权我们访问 Dev-Account-12345 和 Test-Account-67890。

操作完成后，我们访问 AWS 的方式会变为：登录中央的 AWS 访问门户 -> 看到授权给我们的所有账户列表 -> 选择账户和角色 -> 进入控制台。

所以，别再困惑为什么我们的控制台“缺胳膊少腿”了。这恰恰体现了 AWS 设计的精妙之处——职责分离。

我们作为开发者或用户，只需要知道自己的身份在中央被管理，然后通过正确的入口（AWS 访问门户）去访问我们被授予的一切资源即可。