1. 概述
在使用 AWS 服务时，我们经常需要授权用户、应用或其他 AWS 账户访问特定资源或服务。
AWS IAM（Identity and Access Management）提供了多种灵活且安全的权限管理方式，其中 IAM 角色（Role） 是非常关键的一部分。
而 AssumeRolePolicyDocument 就是 IAM 角色的核心配置之一，它定义了谁可以“扮演”这个角色，以及在什么条件下可以扮演。
本文将深入讲解 AssumeRolePolicyDocument 的作用、结构、使用场景及注意事项。
2. 什么是 AssumeRolePolicyDocument？
AssumeRolePolicyDocument 是 IAM 角色的信任策略（Trust Policy），用于定义哪些实体（Principal）可以假扮（Assume）该角色。
创建 IAM 角色时，必须指定这个属性。否则角色将无法被使用。
一个信任策略通常包含一个或多个 Statement，每个 Statement 包含以下关键字段：
- Effect：允许（Allow）或拒绝（Deny）
- Principal：被授权扮演该角色的实体（如服务、用户、账户等）
- Action：允许执行的操作，通常是
sts:AssumeRole - Condition（可选）：附加的限制条件，如 IP 地址、来源等
⚠️ 注意：AssumeRolePolicyDocument 与 IAM 策略（Policy）不同。前者控制谁可以扮演角色，后者定义角色本身拥有的权限。
3. 常见使用场景
3.1 允许 AWS 服务扮演角色（如 Lambda）
这是最常见的一种场景。例如我们希望 Lambda 函数访问 S3 存储桶。
AWSTemplateFormatVersion: 2010-09-09
Parameters:
S3BucketName:
Type: String
Resources:
BaeldungOpsRole:
Type: AWS::IAM::Role
Properties:
RoleName: baeldung-ops-role
Policies:
- PolicyName: s3-bucket-access
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action: s3:GetObject
Resource: !Sub arn:aws:s3:::${S3BucketName}/*
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service: lambda.amazonaws.com
Action: sts:AssumeRole
✅ 说明：
Principal.Service设置为lambda.amazonaws.com表示允许 Lambda 服务使用该角色。!Sub用于动态替换变量，使模板更通用。- 创建 CloudFormation 堆栈时需要添加
CAPABILITY_NAMED_IAM能力，因为模板中使用了自定义命名的 IAM 角色。
3.2 跨账户访问
适用于多账户架构中，允许一个账户中的用户访问另一个账户中的资源。
Parameters:
TrustedAccountId:
Type: String
IAMUserName:
Type: String
Resources:
BaeldungOpsRole:
Type: AWS::IAM::Role
Properties:
RoleName: baeldung-ops-role
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
AWS: !Sub arn:aws:iam::${TrustedAccountId}:user/${IAMUserName}
Action: sts:AssumeRole
✅ 说明：
Principal.AWS指定了信任账户中的用户 ARN。- 除了信任策略，被信任账户中的用户还需在其 IAM 策略中拥有
sts:AssumeRole权限，指向该角色的 ARN。
3.3 联合身份访问（Federated Access）
通过外部身份提供商（如 Cognito、Google、Okta）认证后访问 AWS 资源。
Resources:
BaeldungOpsRole:
Type: AWS::IAM::Role
Properties:
RoleName: baeldung-ops-role
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Federated: cognito-identity.amazonaws.com
Action: sts:AssumeRoleWithWebIdentity
✅ 说明：
- 使用
Federated指定联合身份提供商。 Action使用sts:AssumeRoleWithWebIdentity表示通过 Web 身份认证。- 可通过添加 Condition 进一步限制身份池 ID（见下节）。
3.4 角色链（Role Chaining）
允许一个 IAM 角色扮演另一个 IAM 角色，实现权限的逐级下放。
Parameters:
IAMRoleName:
Type: String
Resources:
BaeldungOpsElevatedRole:
Type: AWS::IAM::Role
Properties:
RoleName: baeldung-ops-elevated-role
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
AWS: !Sub arn:aws:iam::${AWS::AccountId}:role/${IAMRoleName}
Action: sts:AssumeRole
✅ 说明：
- 使用
AWS::AccountId自动填充当前账户 ID。 - 需要确保被允许的角色在其 IAM 策略中也拥有
sts:AssumeRole权限。 - 虽然角色链强大，但应遵循最小权限原则，避免权限过大。
4. 使用 Condition 限制访问
除了指定 Principal，我们还可以通过 Condition 添加额外限制条件，提升安全性。
示例 1：限制 Cognito 用户池 ID
Parameters:
CognitoIdentityPoolId:
Type: String
Condition:
StringEquals:
cognito-identity.amazonaws.com:aud: !Ref CognitoIdentityPoolId
✅ 说明：
StringEquals确保 Cognito token 中的aud值匹配指定的身份池 ID。- 可防止其他身份池用户误用该角色。
示例 2：限制 Lambda 函数来源
Parameters:
LambdaSourceCIDR:
Type: String
LambdaFunctionName:
Type: String
Condition:
IpAddress:
aws:SourceIp: !Ref LambdaSourceCIDR
ArnLike:
aws:SourceArn: !Sub arn:aws:lambda:${AWS::Region}:${AWS::AccountId}:function:${LambdaFunctionName}
✅ 说明：
IpAddress限制源 IP 地址范围（如 VPC CIDR）。ArnLike确保请求必须来自指定 Lambda 函数。
5. 总结
本文详细介绍了 AWS IAM 中的 AssumeRolePolicyDocument，包括其结构、作用及常见使用场景：
- ✅ AWS 服务访问（如 Lambda 访问 S3）
- ✅ 跨账户访问（实现多账户架构中的资源共享）
- ✅ 联合身份访问（支持 Cognito、Google 等认证源）
- ✅ 角色链（实现权限逐级下放）
- ✅ 条件限制（提升安全控制粒度）
合理配置 AssumeRolePolicyDocument，可以有效控制 IAM 角色的使用范围，保障 AWS 资源的安全性。
所有示例模板可在 GitHub 获取：AWS CloudFormation 示例仓库