一、为什么需要 IAM Identity Center
在 AWS 的早期使用方式里，每个开发者通常会拥有一个 IAM 用户，并为其生成一对长期有效的 Access Key 和 Secret Key，写进本地的 ~/.aws/credentials 文件。这种方式简单直接，但随着团队和账号数量的增长，问题会越来越明显。
长期密钥一旦泄露（误提交到 Git 仓库、被恶意软件窃取、离职员工带走），在被发现并手动删除之前会一直有效。多账号环境下，每个人要在每个账号里各有一个 IAM 用户，权限分散在各处，难以审计和回收。员工入职、转岗、离职时，管理员需要逐个账号去增删用户和密钥，极易遗漏。
IAM Identity Center（2022 年前叫 AWS Single Sign-On，简称 AWS SSO）正是为了解决这些问题而设计的。它提供一个统一的身份入口：用户只登录一次，就能访问被授权的多个 AWS 账号和角色，并且所有凭证都是自动签发、自动过期的临时凭证。AWS 官方目前也将其作为人员访问 AWS 的首选方式。
二、核心概念
理解 Identity Center，需要先厘清以下几个概念。
身份源（Identity Source） 决定了用户和组从哪里来。可以使用 Identity Center 自带的目录，也可以对接外部身份提供商，例如 Microsoft Entra ID（原 Azure AD）、Okta、Google Workspace，或者自建的 Active Directory。对接外部 IdP 后，员工用公司账号登录即可，离职时在 IdP 里禁用账号，AWS 访问权限也随之失效。
权限集（Permission Set） 是一组权限策略的模板，例如"只读"、“开发者”、“管理员”。它本身不属于任何账号，而是在被分配时，由 Identity Center 自动在目标账号里创建对应的 IAM 角色（角色名形如 AWSReservedSSO_AdministratorAccess_xxxx）。权限集还定义了会话时长，即签发的临时凭证能用多久，范围是 1 到 12 小时。
账号分配（Account Assignment） 把"谁"、“在哪个账号”、"用哪个权限集"三者绑在一起。例如：开发组在测试账号里拥有开发者权限，在生产账号里只有只读权限。
AWS 访问门户（AWS Access Portal） 是用户登录的网页入口，地址形如 https://d-xxxxxxxxxx.awsapps.com/start（也可以自定义为 https://公司名.awsapps.com/start）。用户在这里能看到自己被授权的所有账号和角色，可以一键进入控制台，也可以获取 CLI 用的临时凭证。
Identity Center 所在区域：Identity Center 实例部署在某一个特定区域中（例如 us-east-1）。CLI 配置时需要填写的 SSO 区域就是这个区域，它与你实际操作资源时使用的区域无关，这一点经常被混淆。
三、工作原理：CLI 是怎么拿到凭证的
整个流程可以分成三层，理解它对后续排错非常有帮助。
第一层：身份认证，获取 SSO 访问令牌。 执行 aws sso login 时，CLI 作为一个 OIDC 客户端，向 Identity Center 的 OIDC 服务注册自己，然后打开浏览器让你登录（可能还会经过公司 IdP 和 MFA）。登录并授权后，CLI 获得一个 SSO 访问令牌（Access Token），以及在新式配置下的刷新令牌（Refresh Token），并缓存到本地 ~/.aws/sso/cache/ 目录。较新版本的 CLI v2 默认使用 PKCE 授权码流程，浏览器授权后自动回调到本机；旧版本或显式指定时则使用设备码流程，需要在网页上确认一串验证码。
第二层：换取角色凭证。 当你执行 aws s3 ls --profile dev 这类命令时，CLI 用上一步的访问令牌调用 Identity Center 的 GetRoleCredentials 接口，指明要哪个账号的哪个角色，换回一组标准的 STS 临时凭证：Access Key ID、Secret Access Key 和 Session Token。这组凭证缓存在 ~/.aws/cli/cache/。
第三层：调用 AWS 服务。 CLI 用这组临时凭证对请求签名，正常调用 S3、EC2 等服务。
这里有两个独立的过期时间。SSO 访问令牌的有效期由 Identity Center 的会话设置决定（默认 8 小时，管理员可调整）；角色凭证的有效期由权限集的会话时长决定（默认 1 小时）。角色凭证过期后，只要 SSO 令牌还有效，CLI 会自动重新换取，你察觉不到；只有当 SSO 令牌本身过期，才需要重新执行 aws sso login。
四、准备工作
开始配置前，需要确认以下几点。
首先，使用 AWS CLI v2。sso-session 的配置方式、令牌自动刷新、PKCE 授权等特性都只在 v2 中提供，v1 不推荐用于 Identity Center。可以用下面的命令检查版本：
aws --version
# 输出应以 aws-cli/2. 开头
其次，向管理员确认两项信息：访问门户的 URL，以及 Identity Center 所在的区域。如果你平时能登录门户网页，URL 就是浏览器地址栏里的那个。
最后，确认管理员已经给你分配了至少一个账号和权限集。登录门户后能看到账号列表，就说明分配正常。
五、使用 aws configure sso 完成配置
这是最推荐的配置方式，CLI 会通过交互引导你完成全部设置。
aws configure sso
整个交互过程如下：
SSO session name (Recommended): mycompany
SSO start URL [None]: https://d-xxxxxxxxxx.awsapps.com/start
SSO region [None]: us-east-1
SSO registration scopes [sso:account:access]:
前四项分别是：会话名（自己起，用于区分不同公司或组织的 Identity Center）、门户 URL、Identity Center 所在区域、授权范围（直接回车使用默认值即可）。
回车后 CLI 会自动打开浏览器。登录并点击"允许访问"后回到终端，CLI 会列出你可以访问的账号：
There are 3 AWS accounts available to you.
> 开发环境, [email protected] (111122223333)
测试环境, [email protected] (444455556666)
生产环境, [email protected] (777788889999)
用方向键选择账号后，如果该账号下你有多个角色，还会让你继续选择角色。之后填写默认区域、输出格式和 profile 名称：
CLI default client Region [None]: ap-northeast-1
CLI default output format [None]: json
CLI profile name [AdministratorAccess-111122223333]: dev-admin
完成后，~/.aws/config 中会生成如下内容：
[profile dev-admin]
sso_session = mycompany
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = ap-northeast-1
output = json
[sso-session mycompany]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access
注意，~/.aws/credentials 文件里不会出现任何密钥，这正是 Identity Center 的意义所在。
六、理解配置结构：sso-session 与 profile
上面的配置被拆成了两部分，这是 CLI v2 引入的新式结构。
[sso-session mycompany] 段描述的是"怎么登录"：去哪个门户、在哪个区域认证。它对应的是第一层的 SSO 令牌。
[profile dev-admin] 段描述的是"登录后扮演谁"：哪个账号、哪个角色，以及操作资源时用的默认区域。它通过 sso_session = mycompany 引用登录信息。
这种拆分带来了一个很实用的好处：多个 profile 可以共享同一个 sso-session，登录一次即可全部使用。例如，你可以手动在 config 里追加更多 profile：
[profile test-dev]
sso_session = mycompany
sso_account_id = 444455556666
sso_role_name = DeveloperAccess
region = ap-northeast-1
[profile prod-readonly]
sso_session = mycompany
sso_account_id = 777788889999
sso_role_name = ReadOnlyAccess
region = ap-northeast-1
此时只需执行一次登录，三个 profile 都能使用：
aws sso login --sso-session mycompany
账号 ID 可以在门户页面或 CLI 交互列表中看到，角色名就是权限集的名称。
此外你可能会在一些旧文档里看到另一种写法，把 sso_start_url、sso_region 直接写在 profile 里，没有 sso-session 段。这是旧式（legacy）配置，仍然可用，但不支持令牌自动刷新，每个 profile 也要各自登录。新配置建议统一使用 sso-session 结构。
七、日常使用
登录
aws sso login --profile dev-admin
# 或者按会话登录，覆盖所有共享该会话的 profile
aws sso login --sso-session mycompany
执行命令
aws s3 ls --profile dev-admin
如果在一个终端里要连续操作同一个账号，可以设置环境变量，省去每次写 --profile：
export AWS_PROFILE=dev-admin # Linux / macOS
$env:AWS_PROFILE = "dev-admin" # Windows PowerShell
确认当前身份
这是排查"我到底在用哪个账号"时最有用的命令：
aws sts get-caller-identity --profile dev-admin
输出中的 Arn 字段会显示类似 arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_AdministratorAccess_xxxx/[email protected]，从中可以看出账号、权限集和登录人。
登出
aws sso logout
这会清除本地缓存的 SSO 令牌和角色凭证。在共用电脑上结束工作时，建议执行一下。
八、特殊环境：没有浏览器怎么办
在远程服务器、Docker 容器或 WSL 中，CLI 可能无法自动打开浏览器。此时有两个选项。
使用 --no-browser 参数，CLI 会打印出授权链接，你可以复制到本地电脑的浏览器中打开：
aws sso login --profile dev-admin --no-browser
如果默认的 PKCE 流程因为回调地址无法访问而失败（例如远程服务器上的本地回调端口在你的浏览器里不可达），可以改用设备码流程，它不依赖本机回调：
aws sso login --profile dev-admin --use-device-code
终端会显示一个网址和一串验证码，在任意设备的浏览器里打开网址、核对验证码并授权即可。
九、与其他工具配合使用
官方 SDK 与主流工具：boto3（Python）、AWS SDK for JavaScript v3、Java SDK v2、Go SDK v2 等都原生支持读取 SSO profile，只需指定 profile 名称即可。Terraform 的 AWS Provider、AWS CDK、SAM CLI 等也都支持。
import boto3
session = boto3.Session(profile_name="dev-admin")
print(session.client("sts").get_caller_identity())
不支持 SSO 的老工具：有些工具只认传统的环境变量或 credentials 文件。这时可以让 CLI 把当前的临时凭证导出来：
eval "$(aws configure export-credentials --profile dev-admin --format env)"
执行后，当前终端里会设置好 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY 和 AWS_SESSION_TOKEN 三个环境变量。--format 还支持 powershell、windows-cmd 等格式。
另一种更优雅的方式是利用 credential_process，让工具在需要时自动调用 CLI 获取凭证：
[profile dev-admin-compat]
credential_process = aws configure export-credentials --profile dev-admin --format process
十、进阶：在 SSO 角色基础上再切换角色
有些组织的权限设计是：Identity Center 只给一个入口角色，真正的操作角色还需要再 AssumeRole 一次（例如跨账号访问某个特定角色）。这种角色链可以直接在配置中表达：
[profile deploy-target]
role_arn = arn:aws:iam::777788889999:role/DeploymentRole
source_profile = dev-admin
region = ap-northeast-1
使用 --profile deploy-target 时，CLI 会先通过 SSO 拿到 dev-admin 的凭证，再用它去扮演 DeploymentRole。前提是目标角色的信任策略允许来自 SSO 角色的扮演请求。需要注意，角色链产生的凭证最长只有 1 小时有效期，这是 AWS 的固定限制。
十一、常见问题排查
| 错误信息 | 原因 | 解决办法 |
|---|---|---|
Error loading SSO Token: Token for ... does not exist | 还没登录过，或缓存被清除 | 执行 aws sso login |
The SSO session associated with this profile has expired or is otherwise invalid | SSO 令牌已过期 | 重新执行 aws sso login |
ForbiddenException: No access | 账号 ID 或角色名写错，或该权限集未分配给你 | 核对 sso_account_id 和 sso_role_name，在门户中确认是否有该角色 |
UnauthorizedException: Session token not found or invalid | 令牌失效或 sso_region 填错 | 检查 sso_region 是否为 Identity Center 所在区域，然后重新登录 |
| 登录正常，但操作的是别的账号 | 环境变量 AWS_ACCESS_KEY_ID 等覆盖了 profile | 执行 env | grep AWS 检查并 unset 掉多余的变量 |
| 浏览器授权后终端一直等待 | PKCE 回调无法到达本机 | 改用 --use-device-code |
遇到问题时，给命令加上 --debug 参数可以看到完整的凭证解析过程，通常能快速定位是哪一层出了问题。
十二、安全实践建议
Identity Center 本身已经解决了长期密钥的大部分风险，但仍有一些值得遵循的习惯。
一是遵循最小权限。日常工作使用只读或开发者权限的 profile，只在必要时切换到管理员 profile，生产环境尤其如此。可以通过 profile 命名（如 prod-readonly、prod-admin）让自己时刻清楚当前的权限级别。
二是合理设置会话时长。管理员应根据权限高低设置不同的权限集会话时长，高权限角色可以设得更短。
三是在身份源侧启用 MFA。无论使用 Identity Center 自带目录还是外部 IdP，都应强制多因素认证，因为一次登录就意味着能访问多个账号。
四是不要把导出的临时凭证写入代码或配置仓库。虽然它们会过期，但在有效期内依然可以被滥用。
五是彻底淘汰旧的 IAM 用户长期密钥。迁移到 Identity Center 后，应删除不再需要的 IAM 用户访问密钥，避免两套体系并存留下隐患。
总结
IAM Identity Center 把"身份"和"权限"从各个 AWS 账号中抽离出来，集中管理，并用临时凭证取代了长期密钥。对 CLI 用户而言，变化其实很小：用 aws configure sso 配置一次，用 aws sso login 登录，之后的使用方式与过去完全一致，只是本地再也不需要保存任何密钥。理解 sso-session 与 profile 的分工、SSO 令牌与角色凭证的两层过期机制，就能应对绝大部分使用场景和问题排查。
如果需要，我可以把这篇文章整理成文档，方便你保存或分享。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/hou478410969/article/details/168523595
