

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# IAM 角色疑難排解
<a name="troubleshoot_roles"></a>

使用此處的資訊，來協助您針對在使用 IAM 角色時所可能遇到的常見問題，進行診斷與排除。

**Topics**
+ [我無法擔任角色](#troubleshoot_roles_cant-assume-role)
+ [我的 AWS 帳戶中出現新角色](#troubleshoot_roles_new-role-appeared)
+ [我無法在 中編輯或刪除角色 AWS 帳戶](#troubleshoot_roles_cant-edit-delete-role)
+ [我未獲授權執行： iam:PassRole](#troubleshoot_roles_not-auth-passrole)
+ [為何我無法擔任具 12 小時工作階段的角色？ (AWS CLI， AWS 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 或 AWS 帳戶 ARN 指定為主體。 AWS 服務 會提供運算資源，例如 Amazon EC2、Amazon ECS、Amazon EKS 和 Lambda，可提供臨時登入資料並自動更新這些登入資料。此可確保您始終擁有一組有效的憑證。對於這些服務，不需要再次擔任目前的角色即可取得臨時憑證。但是，如果您想要傳遞[工作階段標籤](id_session-tags.md)或一個[工作階段政策](access_policies.md#policies_session)，則需要再次擔任目前的角色。若要了解如何修改角色信任政策以新增主要角色 ARN 或 AWS 帳戶 ARN，請參閱 [更新角色信任政策](id_roles_update-role-trust-policy.md)。
+ 當您使用 擔任角色時 AWS 管理主控台，請務必使用角色的確切名稱。在您擔任角色時，角色名稱會區分大小寫。
+ 當您使用 AWS STS API 或 擔任角色時 AWS CLI，請務必在 ARN 中使用角色的確切名稱。在您擔任角色時，角色名稱會區分大小寫。
+ 當您使用 SAML 型聯合身分提供者擔任角色並啟用 SAML 加密時，請確定已上傳 SAML 身分提供者的有效私有解密金鑰。如需詳細資訊，請參閱[管理 SAML 加密金鑰](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption)。
+ 確認您的 IAM 政策對於您要擔任的角色呼叫 `sts:AssumeRole` 授與了許可。您的 IAM 政策的 `Action` 元素必須允許您呼叫 `AssumeRole` 動作。此外，您的 IAM 政策的 `Resource` 元素必須指定您要擔任的角色。例如，`Resource` 元素可以透過其 Amazon Resource Name (ARN) 或萬用字元 (\*) 來指定角色。例如，您必須至少有一個適用政策授與類似如下的許可：

  ```
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::{{account_id_number}}:role/{{role-name-you-want-to-assume}}"
  ```
+ 請確認您的 IAM 身分已用 IAM 政策要求的任何標籤加上標籤。例如，在以下政策許可中，`Condition` 元素要求作為請求擔任該角色的主體，也就是您，必須有特定標籤。您必須以 `department = HR` 或 `department = CS` 加上標籤。否則，您無法擔任該角色。如需有關標記 IAM 使用者和角色的詳細資訊，請參閱 [AWS 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}}"
          }
      }
  ```
+ 確認您呼叫的 AWS 帳戶 `AssumeRole`是您所擔任角色的信任實體。受信任實體被定義為角色的信任政策中的 `Principal`。以下範例是連接到您要擔任之角色的信任政策。在此範例中，您登入所使用的帳戶 ID 和 IAM 使用者必須是 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"}
      }
  ```
+ **來源身分** – 管理員可以設定角色來要求身分傳遞自訂字串，以識別正在其中執行動作的人員或應用程式 AWS，稱為*來源身分*。確認所擔任的角色是否要求設定來源身分。如需來源身分的詳細資訊，請參閱 [監控並控制使用擔任角色所採取的動作](id_credentials_temp_control-access_monitor.md)。

## 我的 AWS 帳戶中出現新角色
<a name="troubleshoot_roles_new-role-appeared"></a>

有些 AWS 服務要求您使用直接連結至服務的唯一服務角色類型。此[服務連結角色](id_roles.md#iam-term-service-linked-role)是由服務預先定義的，並且包含服務所需要的所有許可。這會使設定服務更為簡單，因為您不必手動新增必要的許可。如需服務連結角色的一般資訊，請參閱 [建立服務連結角色](id_roles_create-service-linked-role.md)。

當服務開始支援服務連結的角色時，您可能已經在使用服務。若是如此，您可能會收到一封電子郵件，通知您關於您的帳戶中的新角色。此角色包含服務代表您執行動作所需的所有許可。您不需要執行任何動作來支援此角色。不過，您不應從您的帳戶刪除該角色。如此可能會移除服務存取 AWS 資源所需的許可。您可以前往 IAM 主控台的 IAM **Roles (角色)** 頁面，檢視您帳戶中的服務連結角色。服務連結角色會在表格的 **Trusted entities** (受信任實體) 欄中以 **(Service-linked role)** ((服務連結角色)) 顯示。

如需哪些服務支援服務連結角色的資訊，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)，並尋找在 **Service-Linked Role (服務連結角色)** 一欄中顯示 **Yes (是)** 的服務。如需使用服務的服務連結角色相關資訊，請選擇 **Yes (是)** 連結。

## 我無法在 中編輯或刪除角色 AWS 帳戶
<a name="troubleshoot_roles_cant-edit-delete-role"></a>

您無法在 IAM 中刪除或編輯[服務連結角色](id_roles.md#iam-term-service-linked-role) 的許可。這些角色包括服務所需的預先定義的信任和許可，以代表您執行動作。您可以使用 IAM 主控台 AWS CLI或 API，僅編輯服務連結角色的描述。您可以前往主控台的 IAM **Roles** (角色) 頁面，檢視您帳戶中的服務連結角色。服務連結角色會在表格的 **Trusted entities** (受信任實體) 欄中以 **(Service-linked role)** ((服務連結角色)) 顯示。在 **Summary (摘要)** 頁面上的橫幅，也會指出角色是一個服務連結角色。您可以僅透過連結的服務來管理和刪除這些角色，如果該服務支援動作。修改或刪除服務連結的角色時請務必謹慎，因為這樣可能移除服務存取 AWS 資源所需的許可。

如需哪些服務支援服務連結角色的資訊，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)，並尋找在 **Service-Linked Role** (服務連結角色) 一欄中顯示 **Yes** (是) 的服務。

## 我未獲授權執行： iam:PassRole
<a name="troubleshoot_roles_not-auth-passrole"></a>

當您建立服務連結的角色時，您必須擁有傳遞該角色到服務的許可。有些服務會自動在您在該服務中執行動作時，在您的帳戶中建立服務連結角色。例如，Amazon EC2 Auto Scaling 會在您第一次建立 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` 許可。

若要了解哪些服務支援服務連結角色，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)。若要了解服務是否為您自動建立服務連結角色，請選擇 **Yes (是)** 連結以檢視該服務的服務連結角色文件。

## 為何我無法擔任具 12 小時工作階段的角色？ (AWS CLI， AWS API)
<a name="troubleshoot_roles_cant-set-session"></a>

當您使用 AWS STS `AssumeRole*` API 或 `assume-role*` CLI 操作來擔任角色時，您可以指定 `DurationSeconds` 參數的值。您可以指定從 900 秒 (15 分鐘) 到角色的 **Maximum session duration (最大工作階段持續時間)** 設定的值。如果您指定高於此設定的值，操作會失敗。此設定的上限值為 12 小時。例如，如果您指定 12 小時的工作階段持續時間，但是您的管理員設定最大工作階段持續時間為 6 小時，則您的操作會失敗。若要了解如何檢視角色的最大值，請參閱 [更新角色的最大工作階段持續時間](id_roles_update-role-settings.md#id_roles_update-session-duration)。

如果您使用[*角色鏈結*](id_roles.md#iam-term-role-chaining) (使用角色來擔任第二個角色)，則您的工作階段上限為一小時。如果您隨後使用 `DurationSeconds` 參數提供大於一小時的值，則操作會失敗。

## 當我嘗試在 IAM 主控台中切換角色時收到錯誤
<a name="troubleshoot_roles_cant-switch-role-console"></a>

您在 **Switch Role (切換角色)** 頁面上輸入的資訊必須符合角色的資訊。否則，操作會失敗，並且您會收到下列錯誤：

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

如果您收到此錯誤，請確認下列資訊正確：
+ **帳戶 ID 或別名** – AWS 帳戶 ID 是 12 位數字。您的帳戶可能有別名，這是一個易記的識別符，例如您的公司名稱，可以用來代替您的 AWS 帳戶 ID。您可以在此欄位中使用帳戶 ID 或別名。
+ **角色名稱**：角色名稱會區分大小寫。帳戶 ID 和角色名稱必須符合為角色設定的帳戶 ID 和角色名稱。

如果您持續收到錯誤訊息，請連絡您的管理員以驗證先前的資訊。角色信任政策或 IAM 使用者政策可能會限制您的存取。您的管理員可以驗證這些政策的許可。

## 我的角色具有允許我執行動作的政策，但我收到「存取遭拒」
<a name="troubleshoot_roles_session-policy"></a>

您的角色工作階段可能受工作階段政策限制。當您使用 以程式設計方式[請求臨時安全登入](id_credentials_temp_request.md)資料時 AWS STS，您可以選擇傳遞內嵌或受管[工作階段政策](access_policies.md#policies_session)。工作階段政策是一種進階政策，且您會在以程式設計方式建立角色的暫時憑證工作階段時，以參數方式傳遞。您可以使用 `Policy` 參數傳遞單一 JSON 內嵌工作階段政策文件。您可以使用 `PolicyArns` 參數，指定多達 10 個受管工作階段政策。所產生工作階段的許可會是角色的以身分為基礎的政策和工作階段政策的交集。或者，如果您的管理員或自訂程式為您提供暫時憑證，他們可能已包含限制您存取的工作階段政策。

## 服務未建立角色的預設政策版本
<a name="troubleshoot_serviceroles_edited-policy"></a>

服務角色是服務擔任的角色，以代表您在您的帳戶中執行動作。當您設定某些 AWS 服務環境時，您必須定義服務要擔任的角色。在某些情況下，服務會為您在 IAM 中建立服務角色及其政策。雖然您可以從 IAM 之內修改或刪除服務角色及其政策，但 AWS 不建議這樣做。該角色和政策本應僅供該服務使用。如果您編輯政策並設定另一個環境，當服務嘗試使用相同的角色和政策時，操作可能會失敗。

例如，當您 AWS CodeBuild 第一次使用 時，服務會建立名為 的角色`codebuild-RWBCore-service-role`。該服務角色使用名為 `codebuild-RWBCore-managed-policy` 的政策。如果您編輯政策，它會建立新版本，並將該版本儲存為預設版本。如果您在 中執行後續操作 AWS 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 政策](access_policies_managed-versioning.md)。

**刪除服務角色及其政策**

1. 登入 AWS 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。

1. 在導覽窗格上選擇 **Policies (政策)**。

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. 在導覽窗格中，選擇 **Roles (角色)**。

1. 在角色清單中，選擇您要刪除的角色名稱。

1. 選擇 **Trust relationships (信任關係)** 標籤，以檢視哪些實體可以擔任角色。如果列出服務以外的任何實體，請完成下列任務：

   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. 打開 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md).

1. 請檢查服務是否在 **Service-linked roles (服務連結角色)** 欄位中為 **Yes (是)**。

1. 選擇**是**連結，以檢視該服務的服務連結角色文件。

1. 尋找該服務的 Service-Linked Role Permissions (服務連結角色許可) 區段，以檢視[服務主體](reference_policies_elements_principal.md#principal-services)。

您可以使用 [AWS CLI 命令](id_roles_create_for-service.md#roles-creatingrole-service-cli)或 [AWS 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. 返回需要許可的服務，並使用文件中描述的方法來通知服務有關新的服務角色。