

# 排查 IAM 角色问题
<a name="troubleshoot_roles"></a>

使用此处的信息可帮助您诊断和修复在使用 IAM 角色时可能遇到的常见问题。

**Topics**
+ [我无法代入角色](#troubleshoot_roles_cant-assume-role)
+ [我的 Amazon 账户中出现新角色](#troubleshoot_roles_new-role-appeared)
+ [我无法编辑或删除我的 Amazon Web Services 账户 中的角色](#troubleshoot_roles_cant-edit-delete-role)
+ [我无权执行：iam:PassRole](#troubleshoot_roles_not-auth-passrole)
+ [为什么我无法在 12 小时会话中担任角色？ (Amazon CLI、Amazon API)](#troubleshoot_roles_cant-set-session)
+ [当我尝试在 IAM 控制台中切换角色时收到错误](#troubleshoot_roles_cant-switch-role-console)
+ [我的角色具有一个允许我执行操作的策略，但出现“访问被拒绝”错误](#troubleshoot_roles_session-policy)
+ [服务未创建角色的默认策略版本](#troubleshoot_serviceroles_edited-policy)
+ [控制台中没有服务角色的使用案例](#troubleshoot_serviceroles_console-use-case)

## 我无法代入角色
<a name="troubleshoot_roles_cant-assume-role"></a>

请检查以下事项：
+ 要允许用户在角色会话中重新代入当前角色，请将角色 ARN 或 Amazon Web Services 账户 ARN 指定为角色信任策略中的主体。提供计算资源（例如 Amazon EC2、Amazon ECS、Amazon EKS 和 Lambda）的 Amazon Web Services 服务会提供临时凭证并自动更新这些凭证。这样可以确保您始终拥有一组有效的凭证。对于这些服务，无需重新代入当前角色即可获得临时凭证。但是，如果您需要传递 [会话标签](id_session-tags.md) 或者 [会话策略](access_policies.md#policies_session)，则需要重新代入当前角色。要了解如何修改角色信任策略以添加主体角色 ARN 或 Amazon Web Services 账户 ARN，请参阅 [更新角色信任策略](id_roles_update-role-trust-policy.md)。
+ 当您使用 Amazon Web Services 管理控制台 担任角色时，确保使用角色的确切名称。担任角色时，角色名称区分大小写。
+ 使用 Amazon STS API 或 Amazon CLI 担任角色时，请确保使用 ARN 中角色的确切名称。担任角色时，角色名称区分大小写。
+ 当您使用基于 SAML 的联合身份验证身份提供商代入角色，并且启用了 SAML 加密时，请确保已为 SAML 身份提供商上传了有效的私有解密密钥。有关更多信息，请参阅 [管理 SAML 加密密钥](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)。
+ 验证您的 IAM policy 是否为您授予为要担任的角色调用 `sts:AssumeRole` 的权限。您的 IAM policy 的 `Action` 元素必须允许您调用 `AssumeRole` 操作。此外，您的 IAM policy 的 `Resource` 元素必须指定您要带入的角色。例如，`Resource` 元素可以按其 Amazon Resource Name (ARN) 或按通配符 (\$1) 指定角色。例如，至少一个适用于您的策略必须授予与以下权限类似的权限：

  ```
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::account_id_number:role/role-name-you-want-to-assume"
  ```
+ 验证您的 IAM 身份是否标记有 IAM policy 需要的任何标签。例如，在以下策略权限中，`Condition` 元素要求您（因为主体请求担任该角色）必须具有特定标签。您必须被标记有 `department = HR` 或 `department = CS`。否则，您无法担任该角色。要了解如何标记 IAM 用户和角色，请参阅 [Amazon Identity and Access Management 资源的标签](id_tags.md)。

  ```
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "*",
      "Condition": {"StringEquals": {"aws:PrincipalTag/department": [
              "HR",
              "CS"
          ]}}
  ```
+ 确保您满足角色的信任策略中指定的所有条件。`Condition` 可以指定有效期、外部 ID 或请求必须来自于特定 IP 地址。请考虑以下示例：如果当前日期是指定日期以后的任意时间，则策略根本不会匹配，并且无法为您授予担任该角色的权限。

  ```
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::account_id_number:role/role-name-you-want-to-assume"
      "Condition": {
          "DateLessThan" : {
              "aws:CurrentTime" : "2016-05-01T12:00:00Z"
          }
      }
  ```
+ 验证您用于调用 `AssumeRole` 的 Amazon Web Services 账户 是否为您要代入的角色的受信任实体。在角色的信任策略中将受信任实体定义为 `Principal`。以下示例是一个信任策略，它附加到您要担任的角色。在该示例中，您登录时使用的 IAM 用户的账户 ID 必须是 123456789012。如果您的账号未在角色信任策略的 `Principal` 元素中列出，则无法担任该角色。在访问策略中为您授予何种权限无关紧要。注意，示例策略将权限限制为在 2017 年 7 月 1 日至 2017 年 12 月 31 日 (UTC 时间，这两个日期也包含在内) 之间发生的操作。如果您在上述日期范围之前或之后登录，则策略不匹配，您无法担任该角色。

  ```
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
        "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
      }
  ```
+ **来源身份** — 管理员可以配置角色以要求身份来传递自定义字符串，该字符串标识在 Amazon 中执行操作的个人或应用程序，称为*源身份*。验证所担任的角色是否需要设置源身份。更多有关源身份的信息，请参阅 [监控和控制使用所担任角色执行的操作](id_credentials_temp_control-access_monitor.md)。

## 我的 Amazon 账户中出现新角色
<a name="troubleshoot_roles_new-role-appeared"></a>

某些 Amazon 服务要求您使用直接与该服务相链接的唯一服务角色类型。该[服务相关角色](id_roles.md#iam-term-service-linked-role)由服务预定义，具有服务所需的所有权限。这样您就不必手动添加必要的权限，从而能够更轻松地设置服务。有关服务相关角色的一般信息，请参阅[创建服务相关角色](id_roles_create-service-linked-role.md)。

在开始支持服务相关角色时，您可能已在使用服务。如果事实如此，您可能会收到一封电子邮件，告知您账户中将有新角色。该角色包括此项服务代表您执行操作所需的所有权限。您不需要执行任何操作支持该角色。但是，您不能从账户中删除该角色。这样会删除此项服务访问 Amazon 资源所需的权限。您可以转至 IAM 控制台的 IAM **Roles**（角色）页面来查看您的账户中的服务相关角色。服务相关角色在表的 **Trusted entities**（可信实体）列中随 **(Service-linked role)** [（服务相关角色）] 一起显示。

有关哪些服务支持服务相关角色的信息，请参阅[使用 IAM 的 Amazon 服务](reference_aws-services-that-work-with-iam.md)并查找**服务相关角色**列为**是**的服务。有关使用某个服务的服务相关角色的信息，请选择 **Yes** 链接。

## 我无法编辑或删除我的 Amazon Web Services 账户 中的角色
<a name="troubleshoot_roles_cant-edit-delete-role"></a>

您不能删除或编辑 IAM 中[服务相关角色](id_roles.md#iam-term-service-linked-role)的权限。这些角色包括服务代表您执行操作所需的预定义信任和权限。您可以使用 IAM 控制台、Amazon CLI 或 API 仅编辑服务相关角色的描述。您可以转至控制台中的 IAM **Roles**（角色）页面来查看您的账户中的服务相关角色。服务相关角色在表的 **Trusted entities**（可信实体）列中随 **(Service-linked role)** [（服务相关角色）] 一起显示。角色的 **Summary** 页面上的横幅也指示角色是服务相关角色。您只能通过链接的服务管理和删除这些角色 (如果该服务支持此操作)。修改或删除服务相关角色时要小心，因为这样做可能会删除服务访问 Amazon 资源所需的权限。

有关哪些服务支持服务相关角色的信息，请参阅[使用 IAM 的 Amazon 服务](reference_aws-services-that-work-with-iam.md)并查找**服务相关角色**列为**是**的服务。

## 我无权执行：iam:PassRole
<a name="troubleshoot_roles_not-auth-passrole"></a>

在创建服务相关角色时，您必须有权将该角色传递给服务。在某些服务中执行操作时，该服务自动在您的账户中创建一个服务相关角色。例如，在首次创建 Auto Scaling 组时，Amazon EC2 Auto Scaling 为您创建 `AWSServiceRoleForAutoScaling` 服务相关角色。如果您尝试创建 Auto Scaling 组而没有 `PassRole` 权限，则会出现以下错误：

`ClientError: An error occurred (AccessDenied) when calling the PutLifecycleHook operation: User: arn:aws:sts::111122223333:assumed-role/Testrole/Diego is not authorized to perform: iam:PassRole on resource: arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling`

要纠正该错误，请要求管理员为您添加 `iam:PassRole` 权限。

要了解哪些服务支持服务相关角色，请参阅[使用 IAM 的 Amazon 服务](reference_aws-services-that-work-with-iam.md)。要了解服务是否自动为您创建服务相关角色，请选择**是**链接以查看服务的服务相关角色文档。

## 为什么我无法在 12 小时会话中担任角色？ (Amazon CLI、Amazon API)
<a name="troubleshoot_roles_cant-set-session"></a>

在使用 Amazon STS `AssumeRole*` API 或 `assume-role*` CLI 操作担任角色时，您可以为 `DurationSeconds` 参数指定一个值。您可以指定 900 秒（15 分钟）到角色的**最大会话持续时间**设置之间的值。如果指定的值高于该设置，操作将失败。该设置的最大值为 12 小时。例如，如果您指定的会话持续时间为 12 小时，但管理员设置的最大会话持续时间为 6 小时，您的操作将失败。要了解如何查看您的角色的最大值，请参阅[更新角色的最长会话持续时间](id_roles_update-role-settings.md#id_roles_update-session-duration)。

如果您使用[*角色链*](id_roles.md#iam-term-role-chaining) (使用一个角色担任另一个角色)，您的会话限制为最多 1 小时。如果您随后使用 `DurationSeconds` 参数提供大于 1 小时的值，操作将失败。

## 当我尝试在 IAM 控制台中切换角色时收到错误
<a name="troubleshoot_roles_cant-switch-role-console"></a>

您在**切换角色**页上输入的信息必须与角色的信息匹配。否则，操作失败，您会收到以下错误：

`Invalid information in one or more fields. Check your information or contact your administrator.`

如果您收到此错误，请确认以下信息是否正确：
+ **账户 ID 或别名** – Amazon Web Services 账户 ID 是一组 12 位的数字。您的账户可能有一个别名，这是一个易记标识符，例如您的公司名称，可用来代替您的 Amazon Web Services 账户 ID。您可以在此字段中使用账户 ID 或别名。
+ **角色名称** - 角色名称区分大小写。账户 ID 和角色名称必须与为角色配置的内容匹配。

如果您继续收到错误消息，请与您的管理员联系以验证以前的信息。角色信任策略或 IAM 用户策略可能会限制您的访问权限。您的管理员可以验证这些策略的权限。

## 我的角色具有一个允许我执行操作的策略，但出现“访问被拒绝”错误
<a name="troubleshoot_roles_session-policy"></a>

您的角色会话可能受会话策略的限制。以编程方式使用 Amazon STS [请求临时安全凭证](id_credentials_temp_request.md)时，您可以选择传递内联或托管[会话策略](access_policies.md#policies_session)。会话策略是高级策略，在以编程方式为角色创建临时凭证会话时，这些策略将作为参数进行传递。您可以使用 `Policy` 参数传递单个 JSON 内联会话策略文档。您可以使用 `PolicyArns` 参数指定最多 10 个托管会话策略。生成的会话的权限是角色的基于身份的策略与会话策略的交集。或者，如果您的管理员或自定义程序为您提供临时凭证，它们可能已包含会话策略以限制您的访问。

## 服务未创建角色的默认策略版本
<a name="troubleshoot_serviceroles_edited-policy"></a>

服务角色是服务代表您在您的账户中执行操作而担任的角色。在设置一些 Amazon 服务环境时，您必须为服务定义要代入的角色。在某些情况下，服务会在 IAM 中为您创建服务角色及其策略。尽管您可以从 IAM 内部修改或删除服务角色及其策略，但 Amazon 不建议这样做。角色和策略仅供该服务使用。如果编辑策略并设置另一个环境，则当服务尝试使用相同的角色和策略时，操作可能会失败。

例如，首次使用 Amazon CodeBuild 时，服务会创建一个名为 `codebuild-RWBCore-service-role` 的角色。该服务角色使用名为 `codebuild-RWBCore-managed-policy` 的策略。如果编辑策略，它会创建一个新版本并将该版本保存为默认版本。如果您在 Amazon CodeBuild 中执行后续操作，服务可能会尝试更新策略。如果是这样，您会收到以下错误：

`codebuild.amazon.com did not create the default version (V2) of the codebuild-RWBCore-managed-policy policy that is attached to the codebuild-RWBCore-service-role role. To continue, detach the policy from any other identities and then delete the policy and the role.`

如果您收到此错误，则必须在 IAM 中进行更改，然后才能继续服务操作。首先，将默认策略版本设置为 V1，然后重试该操作。如果先前删除了 V1，或者如果选择 V1 不起作用，则清理并删除现有策略和角色。

有关编辑托管策略的更多信息，请参阅[编辑客户托管策略（控制台）](access_policies_manage-edit-console.md#edit-customer-managed-policy-console)。有关策略版本的更多信息，请参阅[IAM policy 版本控制](access_policies_managed-versioning.md)。

**删除服务角色及其策略**

1. 登录到 Amazon Web Services 管理控制台，然后通过以下网址打开 IAM 控制台：[https://console.aws.amazon.com/iam/](https://console.amazonaws.cn/iam/)。

1. 在导航窗格中，选择**策略**。

1. 在策略列表中，选择要删除的策略的名称。

1. 选择**附加的实体**选项卡可查看哪些 IAM 用户、组或角色使用此策略。如果这些身份中的任何一个使用此策略，请完成以下任务：

   1. 创建具有必要权限的新托管策略。要确保这些身份在操作之前和之后具有相同的权限，请从现有策略中复制 JSON 策略文档。然后创建新的管理型策略并粘贴 JSON 文档，如[使用 JSON 编辑器创建策略](access_policies_create-console.md#access_policies_create-json-editor)中所述。

   1. 对于每个受影响的身份，附加新策略，然后分离旧策略。有关更多信息，请参阅 [添加和删除 IAM 身份权限](access_policies_manage-attach-detach.md)。

1. 在导航窗格中，选择**角色**。

1. 在角色列表中，选择要删除的角色的名称。

1. 选择**信任关系**选项卡以查看哪些实体可以代入该角色。如果列出了服务以外的任何实体，请完成以下任务：

   1. [创建信任这些实体的新角色](id_roles_create_for-user.md#roles-creatingrole-user-console)。

   1. 您在上一步中创建的策略。如果跳过了该步骤，请立即创建新的托管策略。

   1. 通知代入该角色的任何人，他们不能再这样做。向他们提供有关如何代入新角色并具有相同权限的信息。

1. [删除策略](access_policies_manage-delete-console.md#delete-customer-managed-policy-console)。

1. [删除角色](id_roles_manage_delete.md#roles-managingrole-deleting-console)。

## 控制台中没有服务角色的使用案例
<a name="troubleshoot_serviceroles_console-use-case"></a>

某些服务要求您手动创建服务角色才能向服务授予权限，以代表您执行操作。如果该服务未在 IAM 控制台中列出，您必须手动将该服务列为受信任的主体。如果您正在使用的服务或功能的文档中不包含将服务列为受信任主体的说明，请为该页面提供反馈。

要手动创建服务角色，您必须知道将担任该角色的服务的[服务主体](reference_policies_elements_principal.md#principal-services)。服务主体是一个标识符，用于向服务授予权限。服务主体由服务定义。

您可以通过检查以下内容来查找某些服务的服务主体：

1. 打开 [使用 IAM 的 Amazon 服务](reference_aws-services-that-work-with-iam.md)。

1. 检查 **Service-linked roles**（服务相关角色）列中是否具有 **Yes**（是）的服务。

1. 选择**是**链接以查看该服务的服务相关角色文档。

1. 查找该服务的“服务相关角色权限”部分，查看[服务主体](reference_policies_elements_principal.md#principal-services)。

您可以使用 [Amazon CLI 命令](id_roles_create_for-service.md#roles-creatingrole-service-cli)或 [Amazon API 操作](id_roles_create_for-service.md#roles-creatingrole-service-api)手动创建服务角色。要使用 IAM 控制台手动创建服务角色，请完成以下任务：

1. 使用您的账户 ID 创建 IAM 角色。请勿附加策略或授予任何权限。有关更多信息，请参阅 [创建角色，向 IAM 用户授予权限](id_roles_create_for-user.md)。

1. 打开角色并编辑信任关系。角色必须信任该服务，而不是信任该账户。例如，更新以下 `Principal` 元素：

   ```
   "Principal": { "AWS": "arn:aws:iam::123456789012:root" }
   ```

   将主体更改为服务的值，例如 IAM。

   ```
   "Principal": { "Service": "iam.amazonaws.com" }
   ```

1. 通过将权限策略附加到角色来添加服务所需的权限。

1. 返回到需要权限的服务，然后使用记录的方法将新的服务角色通知服务。