# IAM 角色创建
要创建角色，可以使用 AWS 管理控制台、AWS CLI、Tools for Windows PowerShell 或 IAM API。
如果使用的是 AWS 管理控制台，则可使用向导来完成创建角色的步骤。向导的步骤可能稍有不同，具体取决于您是为 AWS 服务、AWS 账户 还是 SAML 或 OIDC 联合主体创建角色。
**IAM 用户的角色**
创建此角色，以在您的 AWS 账户 内或向您拥有的其他 AWS 账户 中定义的角色委派权限。一个账户中的用户可以切换为相同或不同账户中的角色。使用角色过程中，用户只能执行角色允许的操作并且只能访问角色允许的资源；其原始用户权限处于暂停状态。用户退出角色时，恢复原始用户权限。
有关更多信息，请参阅 [创建角色，向 IAM 用户授予权限](id_roles_create_for-user.md)。
有关创建跨账户访问角色的更多信息，请参阅 [使用自定义信任策略创建角色](id_roles_create_for-custom.md)。
**AWS 服务的角色**
创建此角色以将权限委派给可以代表您执行操作的服务。您传递给服务的[服务角色](id_roles.md#iam-term-service-role)必须具有 IAM 策略，该策略具有允许服务执行与该服务关联的操作的权限。每项 AWS 服务都需要不同的权限。
有关创建服务角色的更多信息，请参阅 [创建向 AWS 服务委派权限的角色](id_roles_create_for-service.md)。
有关创建服务相关角色的更多信息，请参阅 [创建服务相关角色](id_roles_create-service-linked-role.md)。
**身份联合验证的角色**
创建此角色可将权限委派给已在 AWS 外部拥有身份的用户。使用身份提供商时，您不必创建自定义登录代码或管理自己的用户身份。您的外部用户通过 IdP 登录，您可以向这些外部身份授予使用您的账户中的 AWS 资源的权限。身份提供商可帮助您确保 AWS 账户的安全，因为您不必在应用程序中分配或嵌入长期安全凭证（如访问密钥）。
有关更多信息，请参阅 [为第三方身份提供者创建角色](id_roles_create_for-idp.md)。
# 创建角色，向 IAM 用户授予权限
您可以使用 IAM 角色提供对 AWS 资源的访问权限。利用 IAM 角色，您可以在您的*信任*账户和其他 AWS *受信任*账户之间建立信任关系。信任账户拥有要访问的资源，受信任账户包含需要资源访问权限的用户。但是，其他账户可以拥有您的账户中的资源。例如，信任账户可能允许受信任账户创建新资源，例如在 Amazon S3 存储桶中创建新对象。在这种情况下，创建资源的账户拥有资源并控制谁可以访问该资源。
创建信任关系后，来自受信任账户的 IAM 用户或应用程序可以使用 AWS Security Token Service (AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 操作。此操作提供临时安全凭证，可用于访问您账户中的 AWS 资源。
账户可由您进行控制，或者具有用户的账户可由第三方进行控制。如果其他具有用户的账户是您无法控制的 AWS 账户，则可使用 `externalId` 属性。外部 ID 可以是您和第三方账户管理员之间达成一致的任何字词或数字。此选项会在信任策略中自动添加一个条件，即仅当请求包括正确的 `sts:ExternalID` 时，该用户才担任该角色。有关更多信息，请参阅 [访问第三方拥有的 AWS 账户](id_roles_common-scenarios_third-party.md)。
有关如何使用角色委派权限的信息，请参阅[角色术语和概念](id_roles.md#id_roles_terms-and-concepts)。有关使用服务角色以允许服务访问账户中的资源的信息，请参阅[创建向 AWS 服务委派权限的角色](id_roles_create_for-service.md)。
## 创建 IAM 角色（控制台）
您可以使用 AWS 管理控制台 创建 IAM 用户可担任的角色。例如，假设贵组织拥有多个 AWS 账户 以便将开发环境与生产环境隔离。有关创建角色（该角色允许开发账户中的用户访问生产账户中的资源）的概述信息，请参阅 [使用不同的开发和生产账户的示例方案](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example)。
**最小权限**
要执行下列步骤，您必须至少具有以下 IAM 权限：
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`
------
#### [ Console ]
1. 登录 AWS 管理控制台，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在控制台的导航窗格中，选择 **Roles**，然后选择 **Create role**。
1. 选择 **AWS 账户** 角色类型。
1. 要为您的账户创建角色，请选择 **This account**（此账户）。要为其他账户创建角色，请选择**其他 AWS 账户**，然后输入要向其授予资源访问权限的**账户 ID**。
指定账户的管理员可向该账户中的任何 IAM 用户授予担任该角色的权限。为此，管理员需要将策略附加到用户或组来授予 `sts:AssumeRole` 操作的权限。该策略必须指定角色的 ARN 作为 `Resource`。
1. 如果您向不受您控制的账户的用户授予权限，并且用户将以编程方式代入此角色，请选择 **Require external ID**（需要外部 ID）。外部 ID 可以是您和第三方账户管理员之间达成一致的任意字词或数字。此选项会在信任策略中自动添加一个条件，即仅当请求包括正确的 `sts:ExternalID` 时，该用户才担任该角色。有关更多信息，请参阅 [访问第三方拥有的 AWS 账户](id_roles_common-scenarios_third-party.md)。
**重要**
选择此选项将仅允许通过 AWS CLI、Tools for Windows PowerShell 或 AWS API 访问该角色。这是因为，您不能使用 AWS 控制台切换到其信任策略中有 `externalId` 条件的角色。但您可以通过使用相关开发工具包编写脚本或应用程序，以编程方式创建此类访问。有关更多信息和示例脚本，请参阅 AWS 安全博客中的[如何启用对 AWS 管理控制台 的跨账户存取](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)。
1. 如果需要将该角色限制为使用多重身份验证 (MFA) 进行登录的用户，请选择 **Require MFA**。这将向角色的信任策略中添加用于检查 MFA 登录的条件。需要担任角色的用户必须使用配置的 MFA 设备中的临时一次性密码进行登录。没有经过 MFA 身份验证的用户无法担任该角色。有关 MFA 的更多信息，请参阅[IAM 中的 AWS 多重身份验证](id_credentials_mfa.md)
1. 选择**下一步**。
1. IAM 包括您的账户中的 AWS 托管策略和客户托管策略的列表。选择要用于权限策略的策略，或选择**创建策略**以打开新的浏览器选项卡并从头开始创建新策略。有关更多信息，请参阅 [创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。在您创建策略后，关闭该选项卡并返回到您的原始选项卡。选中您希望担任角色的任何人具有的权限策略旁边的复选框。如果您愿意，此时可以不选择任何策略，稍后将策略附加到角色。默认情况下，角色没有权限。
1. （可选）设置[权限边界](access_policies_boundaries.md)。这是一项高级功能。
打开**设置权限边界**部分，然后选择**使用权限边界控制最大角色权限**。选择要用于权限边界的策略。
1. 选择**下一步**。
1. 对于**角色名称**，请为您的角色输入一个名称。角色名称在您的 AWS 账户内必须是唯一的。在策略中使用角色名称或将其作为 ARN 的一部分时，角色名称区分大小写。在控制台中向客户显示角色名称时（例如在登录过程中），角色名称不区分大小写。由于多个实体可能引用该角色，因此，角色创建完毕后，您将无法编辑角色名称。
1. （可选）对于 **Description**（描述），输入新角色的描述。
1. 在 **Step 1: Select trusted entities**（步骤 1：选择可信实体）或 **Step 2: Add permissions**（步骤 2：添加权限）部分中的 **Edit**（编辑），以编辑角色的用户案例和权限。您将返回之前的页面进行编辑。
1. （可选）通过以键值对的形式附加标签来向角色添加元数据。有关在 IAM 中使用标签的更多信息，请参阅 [AWS Identity and Access Management 资源的标签](id_tags.md)。
1. 检查角色，然后选择**创建角色**。
**重要**
请注意，这只是所需配置的前半部分。您还必须向受信任账户中的各个用户授予在控制台中切换到此角色或以编程方式担任此角色的权限。有关这一步骤的更多信息，请参阅[向用户授予切换角色的权限](id_roles_use_permissions-to-switch.md)。
------
## 创建 IAM 角色 (AWS CLI)
从 AWS CLI 创建角色涉及几个步骤。当您使用控制台创建角色时，很多步骤会自动完成，但是使用 AWS CLI 时，您必须自行完成每一个步骤。您必须创建角色，然后为角色分配权限策略。（可选）您还可以为您的角色设置[权限边界](access_policies_boundaries.md)。
**创建用于跨账户存取的角色（AWS CLI）**
1. 创建角色：[aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)
1. 将托管权限策略附加到角色：[aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
或者
为角色创建内联权限策略：[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
1. （可选）通过附加标签来向角色添加自定义属性：[aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
有关更多信息，请参阅 [管理 IAM 角色（AWS CLI 或 AWS API）的标签](id_tags_roles.md#id_tags_roles_procs-cli-api)。
1. （可选）为角色设置[权限边界](access_policies_boundaries.md)：[aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)
权限边界控制角色可以具有的最大权限。权限边界是一项高级 AWS 功能。
以下示例演示了在简单环境中创建跨账户角色的前两个最常见的步骤。此示例允许 `123456789012` 账户中的任何用户担任角色并查看 `example_bucket` Amazon S3 存储桶。该示例还假设您使用运行 Windows 的客户端计算机，并且已使用您的账户凭证和区域配置了命令行界面。有关更多信息，请参阅[配置 AWS 命令行界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。
在此示例中，在您创建角色时，在第一个命令中包括以下信任策略。此信任策略允许 `123456789012` 账户中的用户使用 `AssumeRole` 操作担任角色，但前提是用户使用 `SerialNumber` 和 `TokenCode` 参数提供 MFA 身份验证。有关 MFA 的更多信息，请参阅 [IAM 中的 AWS 多重身份验证](id_credentials_mfa.md)。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole",
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
]
}
```
------
**重要**
如果 `Principal` 元素中包含特定 IAM 角色或用户的 ARN，在保存策略时该 ARN 将转换为唯一的主体 ID。如果有人希望通过删除并重新创建角色或用户来提升权限，这样有助于减轻此类风险。您通常不会在控制台中看到这个 ID，因为显示信任策略时它还会反向转换为 ARN。但是，如果您删除角色或用户，则主体 ID 会显示在控制台中，因为 AWS 无法再将其映射回 ARN。因此，如果您删除并重新创建了信任策略的 `Principal` 元素所引用的用户或角色，您必须编辑角色以替换 ARN。
当您使用第二个命令时，您必须将现有托管策略附加到角色。下面的权限策略仅允许担任角色的任何人对 `example_bucket` Amazon S3 存储桶执行 `ListBucket` 操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
]
}
```
------
要创建此 `Test-UserAccess-Role` 角色，您必须先将名为 `trustpolicyforacct123456789012.json` 的上述信任策略保存到本地 `policies` 驱动器中的 `C:` 文件夹。然后，使用名称 `PolicyForRole` 将上述权限策略保存为您的 AWS 账户 中的客户管理型策略。然后您可以使用以下命令来创建角色并附加托管策略。
```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json
# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```
**重要**
请注意，这只是所需配置的前半部分。您还必须对受信任账户中的各个用户授予切换角色的权限。有关这一步骤的更多信息，请参阅[向用户授予切换角色的权限](id_roles_use_permissions-to-switch.md)。
在创建角色并向该角色授予执行 AWS 任务或访问 AWS 资源的权限后，`123456789012` 账户中的任何用户都可以担任该角色。有关更多信息，请参阅 [切换到 IAM 角色（AWS CLI）](id_roles_use_switch-role-cli.md)。
## 创建 IAM 角色 (AWS API)
从 AWS API 创建角色涉及几个步骤。当您使用控制台创建角色时，很多步骤会自动完成，但是使用 API 时，您必须自行完成每一个步骤。您必须创建角色，然后为角色分配权限策略。（可选）您还可以为您的角色设置[权限边界](access_policies_boundaries.md)。
**在代码中创建角色 (AWS API)**
1. 创建角色：[CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
您可以指定一个文件位置作为角色的信任策略。
1. 将托管权限策略附加到角色：[AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
或者
为角色创建内联权限策略：[PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
**重要**
请注意，这只是所需配置的前半部分。您还必须对受信任账户中的各个用户授予切换角色的权限。有关这一步骤的更多信息，请参阅[向用户授予切换角色的权限](id_roles_use_permissions-to-switch.md)。
1. （可选）通过附加标签来向用户添加自定义属性：[TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
有关更多信息，请参阅 [管理 IAM 用户（AWS CLI 或 AWS API）的标签](id_tags_users.md#id_tags_users_procs-cli-api)。
1. （可选）为角色设置[权限边界](access_policies_boundaries.md)：[PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)
权限边界控制角色可以具有的最大权限。权限边界是一项高级 AWS 功能。
在创建角色并向该角色授予执行 AWS 任务或访问 AWS 资源的权限后，您必须向账户中的用户授予允许他们担任该角色的权限。有关担任角色的更多信息，请参阅 [切换到 IAM 角色（AWS API）](id_roles_use_switch-role-api.md)。
## 创建 IAM 角色 (AWS CloudFormation)
有关在 AWS CloudFormation 中创建 IAM 角色的信息，请参阅 *AWS CloudFormation 用户指南*中的[资源和属性参考](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html)和[示例](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples)。
有关 AWS CloudFormation 中的 IAM 模板的更多信息，请参阅*AWS CloudFormation用户指南*中的 [AWS Identity and Access Management 模板代码段](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)。
# 创建向 AWS 服务委派权限的角色
许多 AWS 服务要求您使用角色来允许该服务代表您访问其他服务中的资源。由一项服务担任、代表您执行操作的角色称为[服务角色](id_roles.md#iam-term-service-role)。当某角色为某项服务提供专门用途时，它会被归类为[服务相关角色](id_roles.md#iam-term-service-linked-role)。要查看哪些服务支持使用服务相关角色，或服务是否支持任何形式的临时凭证，请参阅 [使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md)。要了解单个服务如何使用角色，请选择表格中的服务名称以查看该服务对应的文档。
设置 `PassRole` 权限时，应确保用户所传递角色的权限不会超过您希望该用户拥有的权限。例如，可能不允许 Alice 执行任何 Amazon S3 操作。如果 Alice 可以将角色传递给允许 Amazon S3 操作的服务，则该服务可以在执行作业时代表 Alice 执行 Amazon S3 操作。
有关如何通过角色委派权限的信息，请参阅[角色术语和概念](id_roles.md#id_roles_terms-and-concepts)。
## 服务角色权限
您必须配置权限以允许 IAM 实体（用户或角色）创建或编辑服务角色。
**注意**
服务相关角色的 ARN 包括服务主体，它在以下策略中显示为 `SERVICE-NAME.amazonaws.com`。请勿尝试猜测服务主体，因为它区分大小写，并且格式会因 AWS 服务而异。要查看服务的服务主体，请参阅其服务相关角色文档。
**允许 IAM 实体创建特定服务角色**
将以下策略添加到需要创建服务角色的 IAM 实体中。此策略允许您为指定服务创建具有特定名称的服务角色。然后，可将托管或内联策略附加到该角色。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:CreateRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
]
}
```
------
**允许 IAM 实体创建任何服务角色**
AWS 建议您只允许管理用户创建任何服务角色。拥有创建角色和附加任何策略权限的人员可以升级自己的权限。相反，应创建一个策略，允许他们仅创建他们所需的角色，或者让管理员代表他们创建服务角色。
要附加允许管理员访问您整个 AWS 账户 的策略，请使用 [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS 托管策略。
**允许 IAM 实体编辑服务角色**
将以下策略添加到需要编辑服务角色的 IAM 实体中。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "EditSpecificServiceRole",
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:GetRole",
"iam:GetRolePolicy",
"iam:ListAttachedRolePolicies",
"iam:ListRolePolicies",
"iam:PutRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
},
{
"Sid": "ViewRolesAndPolicies",
"Effect": "Allow",
"Action": [
"iam:GetPolicy",
"iam:ListRoles"
],
"Resource": "*"
}
]
}
```
------
**允许 IAM 实体删除特定服务角色**
将以下语句添加到需要删除指定服务角色的 IAM 实体的权限策略。
```
{
"Effect": "Allow",
"Action": "iam:DeleteRole",
"Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```
**允许 IAM 实体删除任何服务相关角色**
AWS 建议您只允许管理用户删除任何服务角色。相反，应创建一个策略，允许他们仅删除他们所需的角色，或者让管理员代表他们删除服务角色。
要附加到允许管理员访问您整个 AWS 账户 的策略，请使用 [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS 托管策略。
## 创建用于 AWS 服务的角色（控制台）
您可使用 AWS 管理控制台创建用于服务的角色。由于某些服务支持多个服务角色，请参阅您的服务的 [AWS 文档](https://docs.aws.amazon.com/)以查看要选择的使用案例。您可以了解如何为角色分配必要的信任策略和权限策略，以便服务能够代表您担任角色。可用于控制您的角色的权限的步骤可能会有所不同，具体取决于服务如何定义使用案例，以及您是否创建了服务相关角色。
------
#### [ Console ]
**创建用于 AWS 服务 的角色（IAM 控制台）**
1. 登录 AWS 管理控制台，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在 IAM 控制台的导航窗格中，选择**角色**，然后选择**创建角色**。
1. 对于 **Trusted entity type**（可信实体类型），选择 **AWS 服务**。
1. 对于**服务或使用案例**，请选择服务，然后选择使用案例。用例由服务定义以包含服务要求的信任策略。
1. 选择**下一步**。
1. 对于**权限策略**，选项取决于您选择的使用案例：
+ 如果服务定义了角色的权限，则您无法选择权限策略。
+ 从一组有限的权限策略中进行选择。
+ 从所有权限策略中进行选择。
+ 不选择任何权限策略，创建角色后创建策略，然后将这些策略附加到该角色。
1. （可选）设置[权限边界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。这是一项高级功能，可用于服务角色，但不可用于服务相关角色。
1. 打开**设置权限边界**部分，然后选择**使用权限边界控制最大角色权限**。
IAM 包括您的账户中的 AWS 托管式策略和客户管理型策略的列表。
1. 选择要用于权限边界的策略。
1. 选择**下一步**。
1. 对于**角色名称**，选项取决于服务：
+ 如果服务定义角色名称，则您无法编辑角色名称。
+ 如果服务定义角色名称的前缀，您可以输入可选的后缀。
+ 如果服务未定义角色名称，您可以为该角色命名。
**重要**
命名角色时，请注意以下事项：
角色名称在您的 AWS 账户 中必须是唯一的，且不能因大小写而变得唯一。
例如，不要同时创建名为 **PRODROLE** 和 **prodrole** 的角色。当角色名称在策略中使用或者作为 ARN 的一部分时，角色名称区分大小写，但是当角色名称在控制台中向客户显示时（例如，在登录期间），角色名称不区分大小写。
创建角色后，您无法编辑该角色的名称，因为其他实体可能会引用该角色。
1. （可选）对于**描述**，输入角色的描述。
1. （可选）要编辑角色的使用案例和权限，请在**步骤 1：选择可信实体**或**步骤 2：添加权限**部分中选择**编辑**。
1. （可选）为了帮助识别、组织或搜索角色，请以键值对形式添加标签。有关在 IAM 中使用标签的更多信息，请参阅《IAM 用户指南》**中的 [AWS Identity and Access Management 资源的标签](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)。
1. 检查该角色，然后选择**创建角色**。
------
## 创建用于服务的角色 (AWS CLI)
从 AWS CLI 创建角色涉及几个步骤。当您使用控制台创建角色时，很多步骤会自动完成，但是使用 AWS CLI 时，您必须自行完成每一个步骤。您必须创建角色，然后为角色分配权限策略。如果您使用的服务是 Amazon EC2，则还必须创建实例配置文件并向其添加角色。（可选）您还可以为您的角色设置[权限边界](access_policies_boundaries.md)。
**从 AWS CLI 为 AWS 服务创建角色**
1. 以下 `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` 命令创建了一个名为 *Test-Role* 的角色并向其附加了信任策略：
`aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`
1. 将托管权限策略附加到角色：[aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)。
例如，以下内容 `attach-role-policy` 命令将名为 `ReadOnlyAccess` 的附加 AWS 托管策略附加到了名为 `ReadOnlyRole` 的 IAM 角色：
`aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`
或者
为角色创建内联权限策略：[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
要添加内联权限策略，请参阅以下示例：
`aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`
1. （可选）通过附加标签来向角色添加自定义属性：[aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
有关更多信息，请参阅 [管理 IAM 角色（AWS CLI 或 AWS API）的标签](id_tags_roles.md#id_tags_roles_procs-cli-api)。
1. （可选）为角色设置[权限边界](access_policies_boundaries.md)：[aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)
权限边界控制角色可以具有的最大权限。权限边界是一项高级 AWS 功能。
如果要将角色与 Amazon EC2 或使用 Amazon EC2 的其他 AWS 服务结合使用，则必须将角色存储在实例配置文件中。实例配置文件是一个角色容器，可在启动时附加到 Amazon EC2 实例。一个实例配置文件只能包含一个 角色，不能提高该限制。如果使用 AWS 管理控制台创建角色，则会为您创建具有与角色相同的名称的实例配置文件。有关实例配置文件的更多信息，请参阅[使用实例配置文件](id_roles_use_switch-role-ec2_instance-profiles.md)。有关如何通过角色启动 EC2 实例的信息，请参阅《*Amazon EC2 用户指南*》中的[控制对 Amazon EC2 资源的访问](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)。
**创建实例配置文件并在其中存储角色 (AWS CLI)**
1. 创建实例配置文件：[aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)
1. 向实例配置文件添加角色：[aws iam add-role-to-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html)
以下 AWS CLI 示例命令集演示了创建角色并附加权限的前两个步骤。它还演示了创建实例配置文件并将角色添加到该配置文件中的两个步骤。此示例信任策略允许 Amazon EC2 服务担任角色并查看 `example_bucket` Amazon S3 存储桶。该示例还假设您使用运行 Windows 的客户端计算机，并且已使用您的账户凭证和区域配置了命令行界面。有关更多信息，请参阅[配置 AWS 命令行界面](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。
在此示例中，在您创建角色时，在第一个命令中包括以下信任策略。此信任策略允许 Amazon EC2 服务代入角色。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
```
------
当您使用第二个命令时，您必须将权限策略附加到角色。下面的示例权限策略仅允许角色对 `example_bucket` Amazon S3 存储桶执行 `ListBucket` 操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
要创建此 `Test-Role-for-EC2` 角色，您必须先将上述名为 `trustpolicyforec2.json` 的信任策略和上述名为 `permissionspolicyforec2.json` 的权限策略保存到您的本地 `C:` 驱动器中的 `policies` 目录。然后，您可以使用以下命令来创建角色，附加策略，创建实例配置文件，并将角色添加到实例配置文件中。
```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json
# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json
# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3
# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```
启动 EC2 实例时，如果您使用 AWS 控制台，请在 **Configure Instance Details (配置实例详细信息)** 页面中指定实例配置文件名称。如果使用 `aws ec2 run-instances` CLI 命令，请指定 `--iam-instance-profile` 参数。
## 创建用于服务的角色 (AWS API)
从 AWS API 创建角色涉及几个步骤。当您使用控制台创建角色时，很多步骤会自动完成，但是使用 API 时，您必须自行完成每一个步骤。您必须创建角色，然后为角色分配权限策略。如果您使用的服务是 Amazon EC2，则还必须创建实例配置文件并向其添加角色。（可选）您还可以为您的角色设置[权限边界](access_policies_boundaries.md)。
**为 AWS 服务创建角色 (AWS API)**
1. 创建角色：[CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
您可以指定一个文件位置作为角色的信任策略。
1. 将托管权限策略附加到角色：[AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
或者
为角色创建内联权限策略：[PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
1. （可选）通过附加标签来向用户添加自定义属性：[TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
有关更多信息，请参阅 [管理 IAM 用户（AWS CLI 或 AWS API）的标签](id_tags_users.md#id_tags_users_procs-cli-api)。
1. （可选）为角色设置[权限边界](access_policies_boundaries.md)：[PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)
权限边界控制角色可以具有的最大权限。权限边界是一项高级 AWS 功能。
如果要将角色与 Amazon EC2 或使用 Amazon EC2 的其他 AWS 服务结合使用，则必须将角色存储在实例配置文件中。实例配置文件是角色的容器。每个实例配置文件只能包含一个角色，不能提高该限制。如果在 AWS 管理控制台中创建角色，则为您创建具有与角色相同的名称的实例配置文件。有关实例配置文件的更多信息，请参阅[使用实例配置文件](id_roles_use_switch-role-ec2_instance-profiles.md)。有关如何通过角色启动 Amazon EC2 实例的信息，请参阅《*Amazon EC2 用户指南*》中的[控制对 Amazon EC2 资源的访问](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)。
**创建实例配置文件并在其中存储角色 (AWS API)**
1. 创建实例配置文件：[CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html)
1. 向实例配置文件添加角色：[AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html)
# 创建服务相关角色
服务相关角色是一种独特类型的 IAM 角色，它与AWS服务直接相关。服务相关角色由服务预定义，具有服务代表您调用其他 AWS 服务所需的所有权限。相关的服务还定义了创建、修改和删除服务相关角色的方式。服务可以自动创建或删除角色。它可能允许您在服务的向导或流程中创建、修改或删除角色。或者，它可能需要您使用 IAM 创建或删除角色。无论使用哪种方法，服务相关角色都可让您简化 服务的设置流程，因为您不必手动添加服务代表您完成操作所需的权限。
**注意**
请记住，服务角色不同于服务相关角色。服务角色是由一项服务担任、代表您执行操作的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)。IAM 管理员可以在 IAM 中创建、修改和删除服务角色。有关更多信息，请参阅《IAM 用户指南》**中的[创建向 AWS 服务 委派权限的角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)。服务关联角色是一种与 AWS 服务 关联的服务角色。服务可以代入代表您执行操作的角色。服务关联角色显示在您的 AWS 账户 中，并由该服务拥有。IAM 管理员可以查看但不能编辑服务关联角色的权限。
链接服务会定义其服务相关角色的权限，除非另外定义，否则仅该服务可以担任角色。定义的权限包括信任策略和权限策略，而且权限策略不能附加到任何其他 IAM 实体。
您必须先删除角色的相关资源，之后才能删除角色。这有助于防止您无意中删除访问这些资源的权限。
**提示**
有关哪些服务支持使用服务相关角色的信息，请参阅 [使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md) 并查找其在**服务相关角色**列中为**是**的服务。请选择**是**与查看该服务的服务关联角色文档的链接。
## 服务相关角色权限
您必须为 IAM 实体（用户、组或角色）配置权限，以允许用户或角色创建或编辑服务相关角色。
**注意**
服务相关角色的 ARN 包括服务主体，它在以下策略中显示为 `SERVICE-NAME.amazonaws.com`。请勿尝试猜测服务主体，因为它区分大小写，并且格式会因 AWS 服务而异。要查看服务的服务主体，请参阅其服务相关角色文档。
**允许 IAM 实体创建特定服务相关角色**
将以下策略添加到需要创建服务相关角色的 IAM 实体中。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
"Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
]
}
```
------
**允许 IAM 实体创建任何服务相关角色**
将以下语句添加到 IAM 实体的权限策略，该实体需要创建服务相关角色或任何包含所需策略的服务角色。此策略语句不允许 IAM 实体将策略附加到该角色。
```
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**允许 IAM 实体编辑任何服务角色的描述**
将以下语句添加到 IAM 实体的权限策略，该实体需要编辑服务相关角色或任何服务角色的描述。
```
{
"Effect": "Allow",
"Action": "iam:UpdateRoleDescription",
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**允许 IAM 实体删除特定服务相关角色**
将以下语句添加到需要删除服务相关角色的 IAM 实体的权限策略。
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```
**允许 IAM 实体删除任何服务相关角色**
将以下语句添加到 IAM 实体的权限策略，该实体需要删除服务相关角色，而不需要删除服务角色。
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```
**允许 IAM 实体将现有角色传递给服务**
有些 AWS 服务允许您将现有角色传递给服务，而不是创建新的服务相关角色。为此，用户必须具有*将角色传递*给服务的权限。将以下语句添加到需要传递角色的 IAM 实体的权限策略。此策略语句还允许实体查看可从中选择要传递的角色的角色列表。有关更多信息，请参阅 [向用户授予权限以将角色传递给 AWS 服务](id_roles_use_passrole.md)。
```
{
"Sid": "PolicyStatementToAllowUserToListRoles",
"Effect": "Allow",
"Action": ["iam:ListRoles"],
"Resource": "*"
},
{
"Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```
## 使用服务相关角色的间接权限
服务相关角色授予的权限可以间接转让给其他用户和角色。AWS 服务使用某个服务相关角色时，该服务相关角色可以使用自己的权限调用其他 AWS 服务。这意味着，如果用户和角色有权调用使用某个服务相关角色的服务，将能够间接访问该服务相关角色可以访问的服务。
例如，在创建 Amazon RDS 数据库实例时，[RDS 的服务相关角色](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html)如果尚不存在，则会自动创建。借助该服务相关角色，RDS 将可以代表您调用 Amazon EC2、Amazon SNS、Amazon CloudWatch Logs 和 Amazon Kinesis 等服务。如果您允许账户中的用户和角色修改或创建 RDS 数据库，则这些用户和角色将可以通过调用 RDS，从而与 Amazon EC2、Amazon SNS、Amazon CloudWatch Logs 日志和 Amazon Kinesis 资源进行间接交互，因为 RDS 会使用其服务相关角色来访问这些资源。
### 创建服务相关角色的方法
您用来创建服务相关角色的方法取决于服务。在某些情况下，无需手动创建服务相关角色。例如，在服务中完成特定操作 (如创建资源) 时，服务可能为您创建服务相关角色。或者，如果您在某项服务开始支持服务相关角色之前已在使用该服务，则该服务可能自动在您的账户中创建角色。要了解更多信息，请参阅[我的 AWS 账户中出现新角色](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared)。
在其他情况下，服务可能支持使用服务控制台、API 或 CLI 手动创建服务相关角色。有关哪些服务支持使用服务相关角色的信息，请参阅 [使用 IAM 的 AWS 服务](reference_aws-services-that-work-with-iam.md) 并查找其在**服务相关角色**列中为**是**的服务。要了解服务是否支持创建服务相关角色，请选择 **Yes** 链接以查看该服务的服务相关角色文档。
如果服务不支持创建角色，则可以使用 IAM 创建服务相关角色。
**重要**
服务相关角色将计入您的 [AWS 账户 中的 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities)限制，但如果您已达到限制，仍可以在账户中创建服务相关角色。只有服务相关角色可以超过此限制。
### 创建服务相关角色（控制台）
在 IAM 中创建服务相关角色之前，请查明链接服务是否已自动创建服务相关角色。此外，需了解您是否能从该服务的控制台、API 或 CLI 创建角色。
**创建服务相关角色（控制台）**
1. 登录 AWS 管理控制台，打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在 IAM 控制台的导航窗格中，选择**角色**。然后，选择**创建角色**。
1. 选择**AWS 服务**角色类型。
1. 选择用于您的服务的用例。使用案例由服务定义以包含服务所需的信任策略。然后选择**下一步**。
1. 选择一个或多个要附加到角色的权限策略。根据您选择的使用案例，服务可能执行以下任意操作：
+ 定义角色所使用的权限。
+ 允许您从一组有限的权限中进行选择。
+ 允许您从任意权限中进行选择。
+ 允许您此时不选择策略，稍后创建策略，然后将这些策略附加到角色。
选中分配您希望角色具有的权限的策略旁边的复选框，然后选择**下一步**。
**注意**
使用角色的任何实体都可以使用您指定的权限。默认情况下，角色没有权限。
1. 对于**角色名称**，角色名称自定义的程度由服务定义。如果服务定义角色的名称，则此选项不可编辑。在其他情况下，服务可能定义角色的前缀并让您输入可选的后缀。
如果可能，请输入要添加到默认名称的角色名称后缀。该后缀可帮助您确定角色的用途。角色名称在您的 AWS 账户内必须是唯一的。名称不区分大小写。例如，您无法同时创建名为 **\$1SAMPLE** 和 **\$1sample** 的角色。由于多个单位可能引用该角色，角色创建完毕后无法编辑角色名称。
1. （可选）对于 **Description**（描述），编辑新服务相关角色的描述。
1. 您无法在创建过程中将标签附加到服务相关角色。有关在 IAM 中使用标签的更多信息，请参阅 [AWS Identity and Access Management 资源的标签](id_tags.md)。
1. 检查角色，然后选择**创建角色**。
### 创建服务相关角色(AWS CLI)
在 IAM 中创建服务相关角色之前，请查明链接服务是否已自动创建服务相关角色，以及您是否能从该服务的 CLI 创建角色。如果服务 CLI 不受支持，您可以使用 IAM 命令创建具有服务担任角色时所需的信任策略和内联策略的服务相关角色。
**创建服务相关角色 (AWS CLI)**
运行如下命令：
```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```
### 创建服务相关角色 (AWS API)
在 IAM 中创建服务相关角色之前，请查明链接服务是否已自动创建服务相关角色，以及您是否能从该服务的 API 创建角色。如果服务 API 不受支持，您可以使用 AWS API 创建具有服务代入角色时所需的信任策略和内联策略的服务相关角色。
**创建服务相关角色 (AWS API)**
使用 [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API 调用。在请求中，指定 `SERVICE_NAME_URL.amazonaws.com` 的服务名称。
例如，要创建 **Lex Bots** 服务相关角色，请使用 `lex.amazonaws.com`。
# 为第三方身份提供者创建角色
您可以使用身份提供程序而不必在 AWS 账户 中创建 IAM 用户。利用身份提供程序 (IdP)，您可以管理 AWS 外部的用户身份，并向这些外部用户身份授予访问您账户中的 AWS 资源的权限。有关联合和身份提供程序的更多信息，请参阅[身份提供程序和 AWS 中的联合身份验证](id_roles_providers.md)。
## 为 OIDC 和 SAML 联合主体创建角色（控制台）
创建角色的过程取决于您选择的第三方提供商：
+ 有关 OpenID Connect（OIDC），请参阅 [创建用于 OpenID Connect 联合身份验证（控制台）的角色](id_roles_create_for-idp_oidc.md)。
+ 有关 SAML 2.0，请参阅[创建用于 SAML 2.0 联合身份验证的角色（控制台）](id_roles_create_for-idp_saml.md)。
## 为联合访问创建角色 (AWS CLI)
从 AWS CLI 中为支持的身份提供程序（OIDC 或 SAML）创建角色的步骤是相同的。区别在于，您在先决条件步骤中创建的信任策略的内容不同。首先，按照**先决条件**部分中针对您正在使用的提供商类型的步骤操作：
+ 有关 OIDC 提供商，请参阅[创建用于 OIDC 的角色的先决条件](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites)。
+ 有关 SAML 提供商，请参阅[创建用于 SAML 的角色的先决条件](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites)。
从 AWS CLI 创建角色涉及几个步骤。当您使用控制台创建角色时，很多步骤会自动完成，但是使用 AWS CLI 时，您必须自行完成每一个步骤。您必须创建角色，然后为角色分配权限策略。（可选）您还可以为您的角色设置[权限边界](access_policies_boundaries.md)。
**创建角色 (AWS CLI)**
1. 创建角色：[aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)
1. 将权限策略附加到角色：[aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)
或者
为角色创建内联权限策略：[aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)
1. （可选）通过附加标签来向角色添加自定义属性：[aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
有关更多信息，请参阅 [管理 IAM 角色（AWS CLI 或 AWS API）的标签](id_tags_roles.md#id_tags_roles_procs-cli-api)。
1. （可选）为角色设置[权限边界](access_policies_boundaries.md)：[aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)
权限边界控制角色可以具有的最大权限。权限边界是一项高级 AWS 功能。
以下示例演示了在简单环境中创建身份提供程序角色的前两个最常见的步骤。此示例允许 `123456789012` 账户中的任何用户担任角色并查看 `example_bucket` Amazon S3 存储桶。该示例还假设您在运行 Windows 的计算机上运行 AWS CLI，并且已使用您的凭证配置了 AWS CLI。有关更多信息，请参阅[配置 AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)。
以下示例信任策略是为用户使用 Amazon Cognito 登录时的移动应用程序设计的。在此示例中，*us-east:12345678-ffff-ffff-ffff-123456* 表示由 Amazon Cognito 分配的身份池 ID。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}
}
```
------
下面的权限策略仅允许担任角色的任何人对 `example_bucket` Amazon S3 存储桶执行 `ListBucket` 操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
```
------
要创建此 `Test-Cognito-Role` 角色，您必须首先将上述名为 `trustpolicyforcognitofederation.json` 的信任策略和上述名为 `permspolicyforcognitofederation.json` 的权限策略保存到您的本地 `policies` 驱动器中的 `C:` 文件夹。然后您可以使用以下命令来创建角色并附加内联策略。
```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json
# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```
## 为联合访问创建角色 (AWS API)
从 AWS CLI 中为支持的身份提供程序（OIDC 或 SAML）创建角色的步骤是相同的。区别在于，您在先决条件步骤中创建的信任策略的内容不同。首先，按照**先决条件**部分中针对您正在使用的提供商类型的步骤操作：
+ 有关 OIDC 提供商，请参阅[创建用于 OIDC 的角色的先决条件](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites)。
+ 有关 SAML 提供商，请参阅[创建用于 SAML 的角色的先决条件](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites)。
**要创建角色（AWS API）**
1. 创建角色：[CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)
1. 将权限策略附加到角色：[AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)
或者
为角色创建内联权限策略：[PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
1. （可选）通过附加标签来向用户添加自定义属性：[TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)
有关更多信息，请参阅 [管理 IAM 用户（AWS CLI 或 AWS API）的标签](id_tags_users.md#id_tags_users_procs-cli-api)。
1. （可选）为角色设置[权限边界](access_policies_boundaries.md)：[PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)
权限边界控制角色可以具有的最大权限。权限边界是一项高级 AWS 功能。
# 创建用于 OpenID Connect 联合身份验证（控制台）的角色
您可以使用 OpenID Connect (OIDC) 联合身份验证身份提供者，而不必在 AWS 账户 中创建 AWS Identity and Access Management 用户。利用身份提供程序 (IdP)，您可以管理 AWS 外部的用户身份，并向这些外部用户身份授予访问您账户中的 AWS 资源的权限。有关联合身份验证和 IdP 的更多信息，请参阅 [身份提供程序和 AWS 中的联合身份验证](id_roles_providers.md)。
## 创建用于 OIDC 的角色的先决条件
您必须先完成以下先决条件步骤，然后才能创建用于 OIDC 联合身份验证的角色。
**准备创建用于 OIDC 联合身份验证的角色**
1. 注册一项或多项提供 OIDC 联合身份的服务。如果创建需要访问 AWS 资源的应用程序，则还需要使用提供商信息来配置应用程序。当您执行此操作时，提供程序会为您提供一个应用程序 ID 或受众 ID，该 ID 在您的应用程序中具有唯一性。（不同的提供程序使用不同的术语表示此过程。此指南使用*配置*一词表示通过提供程序标识应用程序的过程。） 可以对每个提供商配置多个应用程序，也可以对单个应用程序配置多个提供商。查看有关使用身份提供程序的信息，如下所示：
+ [Login with Amazon 开发人员中心](https://login.amazon.com/)
+ 在 Facebook 开发人员网站上，[将 Facebook 登录名添加到您的应用程序或网站](https://developers.facebook.com/docs/facebook-login/v2.1)。
+ 在 Google 开发人员网站上，[使用 OAuth 2.0 进行登录 (OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login)。
1. 从 IdP 接收必要信息后，在 IAM 中创建 IdP。有关更多信息，请参阅 [在 IAM 中创建 OpenID Connect（OIDC）身份提供者](id_roles_providers_create_oidc.md)。
**重要**
如果您使用的是 Google、Facebook 或 Amazon Cognito 的 OIDC IdP，请勿在 AWS 管理控制台 中创建单独的 IAM IdP。这些 OIDC 身份提供程序已内置到 AWS，并可供您使用。跳过此步骤并在以下步骤中使用 IdP 创建新角色。
1. 为已进行 IdP 身份验证的用户要担任的角色准备策略。正如任何角色一样，移动应用程序的角色包含两个策略。一个是指定谁可以担任角色的信任策略。另一个是指定允许或拒绝移动应用程序访问的 AWS 操作和资源的权限策略。
对于 web IdP，我们建议您使用 [Amazon Cognito](https://aws.amazon.com/cognito/) 来管理身份。在这种情况下，请使用类似于以下示例的信任策略。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
"ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
}
}
}
```
------
将 `us-east-2:12345678-abcd-abcd-abcd-123456` 替换为由 Amazon Cognito 分配给您的身份池 ID。
如果您手动配置 OIDC IdP，则在创建信任策略时，必须使用三个值来确保只有您的应用程序可以担任此角色：
+ 对于 `Action` 元素，使用 `sts:AssumeRoleWithWebIdentity` 操作。
+ 对于 `Principal` 元素，使用字符串 `{"Federated":providerUrl/providerArn}`。
+ 对于一些常见的 OIDC IdP，`providerUrl` 是 URL。以下示例包括为一些常见 IdP 指定主体的方法：
`"Principal":{"Federated":"cognito-identity.amazonaws.com"}`
`"Principal":{"Federated":"www.amazon.com"}`
`"Principal":{"Federated":"graph.facebook.com"}`
`"Principal":{"Federated":"accounts.google.com"}`
+ 对于其他的 OIDC 提供程序，请使用您在 [Step 2](#idpoidcstep2) 中创建的 OIDC IdP 的 Amazon 资源名称（ARN），如下例所示：
`"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
+ 对于 `Condition` 元素，使用 `StringEquals` 条件来限制权限。测试身份池 ID（对于 Amazon Cognito）或应用程序 ID（对于其他提供商）。身份池 ID 应与您通过 IdP 配置应用程序时获得的应用程序 ID 一致。ID 一致可确保请求来自您的应用程序。
**注意**
Amazon Cognito 身份池的 IAM 角色信任服务主体 `cognito-identity.amazonaws.com` 担任该角色。此类角色必须包含至少一个条件键来限制可以担任该角色的主体。
其他注意事项适用于承担[跨账户 IAM 角色](access_policies-cross-account-resource-access.md)的 Amazon Cognito 身份池。这些角色的信任策略必须接受 `cognito-identity.amazonaws.com` 服务主体，并且必须包含 `aud` 条件键，以限制预期身份池中的用户担任角色。如果不满足此条件，则信任 Amazon Cognito 身份池的策略会带来风险，即来自非预期身份池的用户可能担任该角色。有关更多信息，请参阅《*Amazon Cognito 开发人员指南*》中的[基本（经典）身份验证中的 IAM 角色的信任策略](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies)。
根据您所使用的 IdP 创建类似于以下示例之一的条件元素：
`"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`
`"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`
`"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`
`"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`
对于 OIDC 提供商，请将 OIDC IdP 的完全限定 URL 与 `aud` 上下文密钥一起使用，如以下示例所示：
`"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**注意**
角色的信任策略中的主体的值将因 IdP 而异。用于 OIDC 的角色只能指定一个主体。因此，如果移动应用程序允许用户从多个 IdP 登录，请为您想要支持的每个 IdP 创建单独角色。为每个 IdP 创建单独的信任策略。
如果用户使用移动应用程序从 Login with Amazon 登录，则将应用以下示例信任策略。在示例中，*amzn1.application-oa2-123456* 表示使用 Login with Amazon 配置应用程序时由 Amazon 分配的应用程序 ID。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForLoginWithAmazon",
"Effect": "Allow",
"Principal": {"Federated": "www.amazon.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
}]
}
```
------
如果用户使用移动应用程序从 Facebook 登录，则将应用以下示例信任策略。在此示例中，*111222333444555* 表示由 Facebook 分配的应用程序 ID。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForFacebook",
"Effect": "Allow",
"Principal": {"Federated": "graph.facebook.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
}]
}
```
------
如果用户使用移动应用程序从 Google 登录，则将应用以下示例信任策略。在此示例中，*666777888999000* 表示由 Google 分配的应用程序 ID。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForGoogle",
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
}]
}
```
------
如果用户使用移动应用程序从 Amazon Cognito 登录，则将应用以下示例信任策略。在此示例中，*us-east:12345678-ffff-ffff-ffff-123456* 表示由 Amazon Cognito 分配的身份池 ID。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "RoleForCognito",
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
}]
}
```
------
## 创建用于 OIDC 的角色
完成先决条件后，您可在 IAM 中创建角色。对于公认的共享 OpenID Connect（OIDC）身份提供者（IdP），IAM 要求对名为*身份提供者控制*的 JSON Web 令牌（JWT）中的特定声明进行明确评估。有关哪些 OIDC IdP 拥有*身份提供者控制*的更多信息，请参阅 [适用于共享 OIDC 提供者的身份提供者控制](id_roles_providers_oidc_secure-by-default.md)。
以下过程介绍了如何在 AWS 管理控制台 中创建用于 OIDC 联合身份验证的角色。要从 AWS CLI 或 AWS API 创建角色，请参阅[为第三方身份提供者创建角色](id_roles_create_for-idp.md)中的过程。
**重要**
如果您使用的是 Amazon Cognito，则使用 Amazon Cognito 控制台来设置角色。否则，请使用 IAM 控制台来创建用于 OIDC 联合身份验证的角色。
**创建用于 OIDC 联合身份验证的 IAM 角色**
1. 登录 AWS 管理控制台，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在导航窗格中，选择**角色**，然后选择**创建角色**。
1. 选择 **Web 身份**作为可信实体类型，然后选择**下一步**。
1. 对于 **Identity provider**（身份提供程序），请为您的角色选择 IdP：
+ 如果要为单个 web IdP 创建角色，请选择 **Login with Amazon**、**Facebook** 或 **Google**。
**注意**
您必须为想要支持的每个 IdP 创建单独的角色。
+ 如果要为 Amazon Cognito 创建高级方案角色，请选择 **Amazon Cognito**。
**注意**
您仅在处理高级方案时需要手动创建与 Amazon Cognito 一起使用的角色。否则，Amazon Cognito 可以为您创建角色。有关 Amazon Cognito 的更多信息，请参阅《*Amazon Cognito 开发人员指南*》中的[身份池（联合身份）外部身份提供商](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html)。
+ 要为 GitHub 操作创建角色，您需要首先将 GitHub OIDC 提供者添加到 IAM。将 GitHub OIDC 提供商添加到 IAM 后，选择 **token.actions.githubusercont.com**。
**注意**
有关如何将 AWS 配置为联合身份以信任 GitHub 的 OIDC 提供商的信息，请参阅 [GitHub 文档 – 在 Amazon Web Services 中配置 OpenID Connect](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)。有关限制与 GitHub IAM IdP 相关的角色访问权限的最佳做法的信息，请参阅此页面上的[为 GitHub OIDC 身份提供程序配置角色](#idp_oidc_Create_GitHub)。
+ 要为 HashiCorp Cloud Platform（HCP）Terraform 创建角色，您首先必须将 Terraform OIDC 提供商添加到 IAM。将 Terraform OIDC 提供商添加到 IAM 后，选择 **app.terraform.io**。
**重要**
HashiCorp Cloud Platform（HCP）Terraform OIDC 提供商的 IAM 角色必须评估角色信任策略中的 IAM 条件键 `app.terraform.io:sub`。此条件键对哪些 HCP Terraform 组织、项目、工作区或运行阶段能够担任该角色作出限制。如果没有此条件键，则您的信任策略将根据组织外部的身份授予对您的角色和 AWS 资源的访问权限，这不符合最低权限原则。
如果您为 AWS 账户中与 HCP Terraform OIDC 提供商关联的角色设置或修改角色信任策略，但未评估 IAM 条件键 `app.terraform.io:sub`，则会收到错误。此外，如果您的角色信任策略未评估此条件键，则 AWS STS 会拒绝授权请求。
1. 所请求的信息因您选择的 OIDC 提供者而异。
+ 输入您的应用程序标识符。标识符的标签会根据所选提供程序发生变化：
+ 如果要为 Login with Amazon 创建角色，请在 **Application ID**（应用程序 ID）框中输入应用程序 ID。
+ 如果要为 Facebook 创建角色，请在 **Application ID**（应用程序 ID）框中输入应用程序 ID。
+ 如果要为 Google 创建角色，请在 **Audience**（受众）框中输入受众名称。
+ 如果要为 Amazon Cognito 创建角色，请在 **Identity Pool ID**（身份池 ID）框中输入您为 Amazon Cognito 应用程序创建的身份池的 ID。
+ 如果您想为 GitHub Actions 创建角色，请输入以下详细信息：
+ 对于 **Audience (受众)**，请选择 `sts.amazonaws.com`。
+ 对于 **GitHub 组织**，输入 GitHub 组织名称。GitHub 组织名称为必填项，必须为包含短划线（-）的字母数字。您不能在 GitHub 组织名称中使用通配符（\$1 和？）。
+ （可选）对于 **GitHub 存储库**，输入 GitHub 存储库名称。如果不指定值，则默认为通配符（`*`）。
+ （可选）对于 **GitHub 分支**，输入 GitHub 分支名称。如果不指定值，则默认为通配符（`*`）。
+ 如果您想为 HashiCorp Cloud Platform（HCP）Terraform 创建角色，则请输入以下详细信息：
+ 对于 **Audience (受众)**，请选择 `aws.workload.identity`。
+ 对于**组织**，输入组织名称。您可以为所有组织指定通配符（`*`）。
+ 对于**项目**，输入项目名称。您可以为所有项目指定通配符（`*`）。
+ 对于**工作区**，输入工作区名称。您可以为所有工作区指定通配符（`*`）。
+ 对于**运行阶段**，输入运行阶段名称。您可以为所有运行阶段指定通配符（`*`）。
1. （可选）对于**条件（可选）**，选择**添加条件**以创建在应用程序的用户可以使用角色授予的权限之前必须满足的其他条件。例如，您可以添加一个条件，仅授权特定 IAM 用户 ID 访问 AWS 资源。创建角色后，您还可以在信任策略中添加条件。有关更多信息，请参阅 [更新角色信任策略](id_roles_update-role-trust-policy.md)。
1. 查看您的 OIDC 信息，然后选择**下一步**。
1. IAM 包括您的账户中的 AWS 托管策略和客户托管策略的列表。选择要用于权限策略的策略，或者选择 **Create policy**（创建策略）以打开新的浏览器选项卡并从头开始创建新策略。有关更多信息，请参阅 [创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。在您创建策略后，关闭该选项卡并返回到您的原始选项卡。选中您希望 OIDC 用户具有的权限策略旁边的复选框。如果您愿意，此时可以不选择任何策略，稍后将策略附加到角色。默认情况下，角色没有权限。
1. （可选）设置[权限边界](access_policies_boundaries.md)。这是一项高级功能。
打开 **Permissions boundary**（权限边界）部分，然后选择 **Use a permissions boundary to control the maximum role permissions**（使用权限边界控制最大角色权限）。选择要用于权限边界的策略。
1. 选择**下一步**。
1. 对于 **Role name**（角色名称），输入一个角色名称。角色名称在您的 AWS 账户内必须是唯一的。不区分大小写。例如，您无法同时创建名为 **PRODROLE** 和 **prodrole** 的角色。由于其他 AWS 资源可能会引用此角色，因此您无法在创建角色后编辑角色名称。
1. （可选）对于 **Description**（描述），输入新角色的描述。
1. 要编辑角色的使用案例和权限，在 **Step 1: Select trusted entities**（步骤 1：选择可信实体）或 **Step 2: Add permissions**（步骤 2：添加权限）部分中选择 **Edit**（编辑）。
1. （可选）要向角色添加元数据，请以键值对的形式附加标签。有关在 IAM 中使用标签的更多信息，请参阅 [AWS Identity and Access Management 资源的标签](id_tags.md)。
1. 检查角色，然后选择**创建角色**。
## 为 GitHub OIDC 身份提供程序配置角色
如果将 GitHub 用作 OpenID Connect（OIDC）身份提供者（IdP），则最佳实践是限制可以代入与该 IAM IdP 关联的角色的实体。如果信任策略中包含条件语句，则可将角色限制为特定的 GitHub 组织、存储库或分支。可以使用条件键 `token.actions.githubusercontent.com:sub` 和字符串条件运算符来限制访问权限。我们建议将条件限制为您 GitHub 组织中的一组特定存储库或分支。有关如何将 AWS 配置为联合身份以信任 GitHub 的 OIDC 的信息，请参阅 [GitHub 文档 – 在 Amazon Web Services 中配置 OpenID Connect](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)。
如果您在操作工作流或 OIDC 策略中使用 GitHub 环境，我们强烈建议您在环境中添加保护规则以提高安全性。使用部署分支和标签来限制可以部署到环境中的具体分支和标签。有关使用保护规则配置环境的更多信息，请参阅 GitHub 文章“使用环境进行部署”中的 [部署分支和标签](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags)**。
如果 GitHub 的 OIDC IdP 是角色的可信主体，IAM 会检查角色信任策略条件，以验证条件键 `token.actions.githubusercontent.com:sub` 是否存在并且其值并非单纯的通配符（\$1 和 ?）或者为空。创建或更新信任策略时，IAM 会执行此检查。如果条件键 `token.actions.githubusercontent.com:sub` 不存在，或者键值不符合上述值标准，则请求将会失败并返回错误。
**重要**
如果未将条件键 `token.actions.githubusercontent.com:sub` 限制为特定的组织或存储库，则来自您控制范围之外的组织或存储库的 GitHub 操作可代入与您 AWS 账户中的 GitHub IAM IdP 关联的角色。
以下示例信任策略限制对定义的 GitHub 组织、存储库和分支的访问。以下示例中的条件键 `token.actions.githubusercontent.com:sub` 的值是 GitHub 记录的默认主题值格式。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
}
}
}
]
}
```
------
以下示例条件限制对定义的 GitHub 组织和存储库的访问，但授予对存储库内任何分支的访问权限。
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
}
}
```
以下示例条件限制对定义的 GitHub 组织内任何存储库或分支的访问。我们建议将条件键 `token.actions.githubusercontent.com:sub` 限制为一个特定的值，从而确保只能从 GitHub 组织内访问 GitHub 操作。
```
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
}
}
```
有关可用于策略中的条件检查的 OIDC 联合身份验证密钥的更多信息，请参阅 [AWS OIDC 联合身份验证的可用键](reference_policies_iam-condition-keys.md#condition-keys-wif)。
# 创建用于 SAML 2.0 联合身份验证的角色（控制台）
您可以使用 SAML 2.0 联合身份验证而不必在 AWS 账户 中创建 IAM 用户。利用身份提供程序 (IdP)，您可以管理 AWS 外部的用户身份，并向这些外部用户身份授予访问您账户中的 AWS 资源的权限。有关联合和身份提供程序的更多信息，请参阅[身份提供程序和 AWS 中的联合身份验证](id_roles_providers.md)。
**注意**
为了提高联合身份验证弹性，我们建议您将 IdP 和AWS联合身份验证配置为支持多个 SAML 登录端点。有关详细信息，请参阅 AWS 安全博客文章[如何使用区域性 SAML 端点进行失效转移](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)。
## 创建用于 SAML 的角色的先决条件
您必须先完成以下先决条件步骤，然后才能创建用于 SAML 2.0 联合身份验证的角色。
**准备创建用于 SAML 2.0 联合的角色**
1. 在创建用于 SAML 联合的角色之前，必须在 IAM 中创建 SAML 提供商。有关更多信息，请参阅 [在 IAM 中创建 SAML 身份提供者](id_roles_providers_create_saml.md)。
1. 为已进行 SAML 2.0 身份验证的用户要担任的角色准备策略。正如任何角色一样，用于 SAML 联合的角色包含两个策略。一个是指定谁可以代入角色的角色信任策略。另一个是指定允许或拒绝 SAML 联合主体访问的 AWS 操作和资源的 IAM 权限策略。
在为角色创建信任策略时，必须使用三个值来确保只有您的应用程序可以代入此角色：
+ 对于 `Action` 元素，使用 `sts:AssumeRoleWithSAML` 操作。
+ 对于 `Principal` 元素，使用字符串 `{"Federated":ARNofIdentityProvider}`。将 `ARNofIdentityProvider` 替换为您在[Step 1](#idpsamlstep1) 中创建的 [SAML 身份提供程序](id_roles_providers_saml.md)的 ARN。
+ 对于 `Condition` 元素，使用 `StringEquals` 条件测试 SAML 响应中的 `saml:aud` 属性是否匹配登录控制台时浏览器显示的 URL。此登录端点 URL 是您的身份提供者的 SAML 收件人属性。您可以添加特定区域内的登录 URL。AWS 建议使用区域端点而不是全局端点，以提高联合身份验证的韧性。有关可能的 *region-code* 值的列表，请参阅 [AWS 登录端点](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)中的 **Region**（区域）列。
如果需要 SAML 加密，则登录 URL 必须包含 AWS 分配给您的 SAML 提供商的唯一标识符。您可以通过在 IAM 控制台中选择身份提供者并显示详细信息页面来查看唯一标识符。
`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`
以下示例信任策略是为 SAML 联合身份用户设计的：
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRoleWithSAML",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
},
"Condition": {
"StringEquals": {
"SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
}
}
}
}
```
------
将主体 ARN 替换为您在 IAM 中创建的 SAML 提供商的实际 ARN。它会具备您自己的账户 ID 和提供商名称。
## 创建用于 SAML 的角色
在完成先决条件步骤后，您可以创建用于基于 SAML 的联合身份验证的角色。
**要创建用于基于 SAML 的联合的角色，请执行以下操作**
1. 登录 AWS 管理控制台，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在 IAM 控制台的导航窗格中，依次选择**角色**和**创建角色**。
1. 选择 **SAML 2.0 federation** 角色类型。
1. 对于 **Select a SAML provider**（选择 SAML 提供商），请为您的角色选择提供商。
1. 选择 SAML 2.0 访问级别方法。
+ 选择 **Allow programmatic access only (只允许编程访问)** 以创建可从 AWS API 或 AWS CLI 以编程方式担任的角色。
+ 选择**允许编程访问和 AWS 管理控制台 访问**以创建可以编程方式和从 AWS 管理控制台 中担任的角色。
通过这两种方法创建的角色类似，但也可从控制台担任的角色包括包含带特定条件的信任策略。该条件可以显式的方式确保将 SAML 受众（`SAML:aud` 属性）设置为 SAML 提供商的 AWS 登录端点。
1. 定义属性的过程因访问权限类型而异。
+ 如果创建用于编程访问的角色，请从**属性**列表中选择一个属性。然后在 **Value**（值）框中，键入一个将包含在角色中的值。这样可仅限来自其 SAML 身份验证响应 (断言) 包括您指定的属性的身份提供程序的用户可访问该角色。必须指定至少一个属性，以确保您的角色限于您所在组织中的一部分用户。
+ 如果您要为编程和 AWS 管理控制台访问权限创建角色，则**登录端点**部分会定义在登录控制台时浏览器显示的 URL。此端点是您的身份提供者的 SAML 收件人属性，它映射到 [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml) 上下文键。有关更多信息，请参阅 [为身份验证响应配置 SAML 断言。](id_roles_providers_create_saml_assertions.md)。
1. 选择**区域端点**或**非区域端点**。我们建议使用多个区域 SAML 登录端点来提高联合身份验证的韧性。
1. 对于**区域**，请选择您的 SAML 提供商支持 AWS 登录的区域。
1. 要使**登录 URL 包含唯一标识符**，请选择登录端点是否包含 AWS 分配给 SAML 身份提供者的唯一标识符。对于加密的 SAML 断言，此选项为必选项。有关更多信息，请参阅 [SAML 2.0 联合身份验证](id_roles_providers_saml.md)。
1. 要将更多与属性相关的条件添加到信任策略，请选择 **Condition (optional)** [条件（可选）]，选择其他条件，然后指定值。
**注意**
列表包括最常用的 SAML 属性。IAM 支持其他可用于创建条件的属性。有关支持的属性的列表，请参阅 [SAML 联合身份验证的可用键](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml)。如果需要不在列表中的支持的 SAML 属性的条件，可以手动添加此条件。为此，请在创建角色后编辑信任策略。
1. 检查 SAML 2.0 信任信息，然后选择 **Next**（下一步）。
1. IAM 包括您的账户中的 AWS 托管策略和客户托管策略的列表。选择要用于权限策略的策略，或者选择 **Create policy**（创建策略）以打开新的浏览器选项卡并从头开始创建新策略。有关更多信息，请参阅 [创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。在您创建策略后，关闭该选项卡并返回到您的原始选项卡。选择您希望 SAML 联合用户具有的权限策略旁边的复选框。如果您愿意，此时可以不选择任何策略，稍后将策略附加到角色。默认情况下，角色没有权限。
1. （可选）设置[权限边界](access_policies_boundaries.md)。这是一项高级功能。
打开 **Permissions boundary**（权限边界）部分，然后选择 **Use a permissions boundary to control the maximum role permissions**（使用权限边界控制最大角色权限）。选择要用于权限边界的策略。
1. 选择**下一步**。
1. 选择**下一步：审核**。
1. 对于 **Role name**（角色名称），输入一个角色名称。角色名称在您的 AWS 账户 内必须是唯一的。名称不区分大小写。例如，您无法同时创建名为 **PRODROLE** 和 **prodrole** 的角色。由于其他 AWS 资源可能引用该角色，角色创建完毕后无法编辑角色名称。
1. （可选）对于 **Description**（描述），输入新角色的描述。
1. 在 **Step 1: Select trusted entities**（步骤 1：选择可信实体）或 **Step 2: Add permissions**（步骤 2：添加权限）部分中的 **Edit**（编辑），以编辑角色的用户案例和权限。
1. （可选）通过以键值对的形式附加标签来向角色添加元数据。有关在 IAM 中使用标签的更多信息，请参阅 [AWS Identity and Access Management 资源的标签](id_tags.md)。
1. 检查角色，然后选择**创建角色**。
创建角色后，通过使用有关 AWS 的信息来配置您的身份提供程序软件，以完成 SAML 信任。此类信息包括您希望 SAML 联合用户使用的角色。这称为在 IdP 和 AWS 之间配置信赖方信任。有关更多信息，请参阅 [配置具有依赖方信任的 SAML 2.0 IdP 并添加陈述](id_roles_providers_create_saml_relying-party.md)。
# 使用自定义信任策略创建角色
您可以创建自定义信任策略来委派访问权限并允许其他人在您的 AWS 账户 中执行操作。有关更多信息，请参阅 [创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。
有关如何使用角色委派权限的信息，请参阅[角色术语和概念](id_roles.md#id_roles_terms-and-concepts)。
## 使用自定义信任策略创建 IAM 角色（控制台）
您可以使用 AWS 管理控制台 创建 IAM 用户可担任的角色。例如，假设贵组织拥有多个 AWS 账户 以便将开发环境与生产环境隔离。有关创建角色（该角色允许开发账户中的用户访问生产账户中的资源）的概述信息，请参阅 [使用不同的开发和生产账户的示例方案](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example)。
**使用自定义信任策略创建角色（控制台）**
1. 登录 AWS 管理控制台，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。
1. 在控制台的导航窗格中，选择 **Roles**，然后选择 **Create role**。
1. 选择 **Custom trust policy**（自定义信任策略）角色类型。
1. 在 **Custom trust policy**（自定义信任策略）部分，输入或粘贴角色的自定义信任策略。有关更多信息，请参阅 [创建 IAM 策略](access_policies_create-console.md#access_policies_create-start)。
1. 解决[策略验证](access_policies_policy-validator.md)过程中生成的任何安全警告、错误或常规警告，然后选择 **Next**（下一步）。
1. （可选）设置[权限边界](access_policies_boundaries.md)。这是一项高级功能，可用于服务角色，但不可用于服务相关角色。
打开 **Permissions boundary**（权限边界）部分，然后选择 **Use a permissions boundary to control the maximum role permissions**（使用权限边界控制最大角色权限）。IAM 包括您的账户中的 AWS 托管策略和客户托管策略的列表。选择要用于权限边界的策略。
1. 选择**下一步**。
1. 对于**角色名称**，角色名称自定义的程度由服务定义。如果服务定义角色的名称，则此选项不可编辑。在其他情况下，服务可能定义角色的前缀并允许您键入可选的后缀。某些服务允许您指定角色的整个名称。
如果可能，输入角色名称或角色名称后缀。角色名称在您的 AWS 账户 内必须是唯一的。名称不区分大小写。例如，您无法同时创建名为 **PRODROLE** 和 **prodrole** 的角色。由于其他 AWS 资源可能引用该角色，角色创建完毕后无法编辑角色名称。
1. （可选）对于 **Description**（描述），输入新角色的描述。
1. （可选）在**步骤 1：选择受信任的实体**或**步骤 2：添加权限**部分中选择**编辑**，以编辑角色的自定义策略和权限。
1. （可选）通过以键值对的形式附加标签来向角色添加元数据。有关在 IAM 中使用标签的更多信息，请参阅 [AWS Identity and Access Management 资源的标签](id_tags.md)。
1. 检查角色，然后选择**创建角色**。
# 委派访问权限的策略示例
以下示例演示了如何允许或授权 AWS 账户 访问其他 AWS 账户 中的资源。要了解如何使用这些示例 JSON 策略文档创建 IAM policy，请参阅。[使用 JSON 编辑器创建策略](access_policies_create-console.md#access_policies_create-json-editor)
**Topics**
+ [使用角色委托针对其他 AWS 账户 资源的访问权限](#example-delegate-xaccount-rolesapi)
+ [使用策略将访问权限委托给服务](#id_roles_create_policy-examples-access-to-services)
+ [使用基于资源的策略委托访问另一个账户的 Amazon S3 存储桶](#example-delegate-xaccount-S3)
+ [使用基于资源的策略委托针对另一个账户中的 Amazon SQS 队列的访问权限](#example-delegate-xaccount-SQS)
+ [当拒绝访问账户时，不得委托访问](#example-delegate-xaccount-SQS-denied)
## 使用角色委托针对其他 AWS 账户 资源的访问权限
有关介绍如何使用 IAM 角色对一个账户中的用户授权以访问另一个账户中 AWS 资源的教程，请参阅 [IAM 教程：使用 IAM 角色委托跨 AWS 账户的访问权限](tutorial_cross-account-with-roles.md)。
**重要**
您可以在角色信任策略的 `Principal` 元素中包含特定角色或用户的 ARN。保存策略时，AWS 将该 ARN 转换为唯一主体 ID。如果有人希望通过删除并重新创建角色或用户来提升特权，这样有助于减轻此类风险。您通常不会在控制台中看到这个 ID，因为显示信任策略时它还会反向转换为 ARN。但是，如果您删除角色或用户，这种关系即被打破。即使您重新创建用户或角色，策略也不再适用。因为与信任策略中存储的 ID 不匹配。在这种情况下，主体 ID 会显示在控制台中，因为 AWS 无法将其映射回 ARN。结果是，如果您删除并重新创建了信任策略的 `Principal` 元素所引用的用户或角色，您必须编辑角色，替换 ARN。当您保存策略时，它会转换为新的主体 ID。
## 使用策略将访问权限委托给服务
以下示例显示了一个可以附加到角色的策略。该策略可使两个服务 Amazon EMR 和 AWS Data Pipeline 担任此角色。然后，这些服务可执行由分配给该角色 (未显示) 的权限策略授权执行的任何任务。要指定多个服务主体，不用指定两个 `Service` 元素；您可以只使用一个该元素。实际上，您可以将一组多个服务主体作为单个 `Service` 元素的值。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"elasticmapreduce.amazonaws.com",
"datapipeline.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## 使用基于资源的策略委托访问另一个账户的 Amazon S3 存储桶
在此示例中，账户 A 使用基于资源的策略（一个 Amazon S3 [存储桶策略](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html)）授权账户 B 针对账户 A 的 S3 存储桶的完全访问权限。然后，账户 B 创建一个 IAM 用户策略，向账户 B 中的一个用户授予针对账户 A 的存储桶的访问权限。
账户 A 中的 S3 存储桶策略可能与以下策略类似。在此示例中，账户 A 的 S3 存储桶名为 *amzn-s3-demo-bucket*，账户 B 的账号为 111122223333。它在账户 B 中未指定任何单个用户或组，仅指定账户本身。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBAccess1",
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
或者，账户 A 可使用 Amazon S3 [访问控制列表 (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html) 来授权账户 B 访问 S3 存储桶或某个存储桶内的单个对象。在这种情况下，唯一改变的是账户 A 授权访问账户 B 的方式。如此示例的下一个部分所述，账户 B 仍使用一个策略委托针对账户 B 中的 IAM 组的访问权限。有关控制对 S3 存储桶和对象访问的更多信息，请转到 *Amazon Simple Storage Service 用户指南*中的[访问控制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html)。
账户 B 的管理员可能创建以下策略示例。该策略向账户 B 中的组或用户授予读取访问权限。前一策略向账户 B 授予访问权限。但是，除非组或用户策略显式授予资源访问权限，否则账户 B 中的单个组和用户不能访问资源。此策略中的权限只能是上述跨账户策略中的权限的一个子集。相比于账户 A 在第一个策略中授予账户 B 的权限，账户 B 无法向其组和用户授予更多权限。在该策略中，将显式定义 `Action` 元素以仅允许 `List` 操作，而且该策略的 `Resource` 元素与由账户 A 执行的存储桶策略的 `Resource` 匹配。
为执行该策略，账户 B 使用 IAM 将它附加到账户 B 中的相应用户（或组）。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:List*",
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}
}
```
------
## 使用基于资源的策略委托针对另一个账户中的 Amazon SQS 队列的访问权限
在以下示例中，账户 A 有一个 Amazon SQS 队列，该队列使用附加到该队列的基于资源的策略向账户 B 授权队列访问权限。然后，账户 B 使用 IAM 组策略委托针对账户 B 中的组的访问权限。
以下示例队列策略授予账户 B 对名为 执行 *queue1* 的账户 A 的队列执行 `SendMessage`和 `ReceiveMessage` 操作的权限，但只在 2014 年 11 月 30 日中午至下午 3:00 之间可行。Account B 的账号为 1111-2222-3333。账户 A 使用 Amazon SQS 执行该策略。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": ["arn:aws:sqs:*:123456789012:queue1"],
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
"DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
}
}
}
```
------
账户 B 向账户 B 中的组委托访问权限的策略可能类似于以下示例。账户 B 使用 IAM 将此策略附加到组（或用户）。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:queue1"
}
}
```
------
在前述 IAM 用户策略示例中，账户 B 使用通配符授权其用户访问针对账户 A 的队列的所有 Amazon SQS 操作。但是账户 B 可委托的范围仅限于账户 B 被授权访问的范围。拥有第二个策略的账户 B 组只能在 2014 年 11 月 30 日中午至下午 3:00 之间访问该队列。根据账户 A 的 Amazon SQS 队列策略的定义，用户只能执行 `SendMessage` 和 `ReceiveMessage` 操作。
## 当拒绝访问账户时，不得委托访问
如果其他账户已显式拒绝访问用户的父账户，则 AWS 账户 不得委托针对该账户的资源的访问权限。此“拒绝”将传播到该账户内的所有用户，无论用户的现有策略是否授予这些用户访问权限。
例如，账户 A 编写了一个针对其账户中 S3 存储桶的存储桶策略，其中显式拒绝了账户 B 访问账户 A 的存储桶。但账户 B 编写了一个 IAM 用户策略，其中对账户 B 中的一个用户授予了对账户 A 的存储桶的访问权限。应用于账户 A 的 S3 存储桶的“显式拒绝”将传播到账户 B 中的用户。它会覆盖用于对账户 B 中用户授予访问权限的 IAM 用户策略。(有关如何计算权限的详细信息，请参阅 [策略评估逻辑](reference_policies_evaluation-logic.md)。)
Account A 的存储段策略可能与下列策略类似。在此示例中，账户 A 的 S3 存储桶名为 *amzn-s3-demo-bucket*，账户 B 的账号为 1111-2222-3333。账户 A 使用 Amazon S3 执行该策略。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Sid": "AccountBDeny",
"Effect": "Deny",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
}
}
```
------
此“显式拒绝”将覆盖账户 B 中所有提供账户 A 中 S3 存储桶访问权限的策略。