# 为第三方身份提供者创建角色
您可以使用身份提供程序而不必在 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)。