選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

IAM 角色疑難排解

焦點模式
IAM 角色疑難排解 - AWS Identity and Access Management

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

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

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

我無法擔任角色

請檢查以下內容:

  • 若要允許使用者在角色工作階段中再次擔任目前角色,請在角色信任政策中指定角色 ARN 或 AWS 帳戶 ARN 作為主體。提供 Amazon EC2、Amazon ECS、Amazon EKS 和 Lambda 等運算資源的 AWS 服務 提供臨時憑證並自動更新這些憑證。此可確保您始終擁有一組有效的憑證。對於這些服務,不需要再次擔任目前的角色即可取得臨時憑證。但是,如果您想要傳遞工作階段標籤或一個工作階段政策,則需要再次擔任目前的角色。若要了解如何修改角色信任原則以新增主體角色 ARN 或 AWS 帳戶 ARN,請參閱 更新角色信任政策

  • 當您使用 AWS Management Console 來擔任角色,請務必使用與您角色完全相同的名稱。在您擔任角色時,角色名稱會區分大小寫。

  • 當您使用 AWS STS API 或 AWS CLI 來擔任角色,請務必使用與您 ARN 中的角色完全相同的名稱。在您擔任角色時,角色名稱會區分大小寫。

  • 當您使用 SAML 型聯合身分提供者擔任角色並啟用 SAML 加密時,請確定已上傳 SAML 身分提供者的有效私有解密金鑰。如需詳細資訊,請參閱管理 SAML 加密金鑰

  • 確認您的 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 = HRdepartment = CS 加上標籤。否則,您無法擔任該角色。如需有關標記 IAM 使用者和角色的詳細資訊,請參閱 AWS Identity and Access Management 資源的標籤

    "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 的 AWS 帳戶 是您將擔任的角色信任的實體。受信任實體被定義為角色的信任政策中的 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 中執行動作的人員或應用程式,稱為來源身分。確認所擔任的角色是否要求設定來源身分。如需來源身分的詳細資訊,請參閱 監控並控制使用擔任角色所採取的動作

顯示在我的 AWS 帳戶中的新角色

有些 AWS 服務需要您使用會直接連結到服務的唯一類型的服務角色。此服務連結角色是由服務預先定義的,並且包含服務所需要的所有許可。這會使設定服務更為簡單,因為您不必手動新增必要的許可。如需服務連結角色的一般資訊,請參閱 建立服務連結角色

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

如需哪些服務支援服務連結角色的資訊,請參閱 AWS 使用 IAM 的 服務,並尋找在 Service-Linked Role (服務連結角色) 一欄中顯示 Yes (是) 的服務。如需使用服務的服務連結角色相關資訊,請選擇 Yes (是) 連結。

我無法編輯或刪除我的 AWS 帳戶 中的角色

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

如需哪些服務支援服務連結角色的資訊,請參閱 AWS 使用 IAM 的 服務,並尋找在 Service-Linked Role (服務連結角色) 一欄中顯示 Yes (是) 的服務。

我未獲授權執行: iam:PassRole

當您建立服務連結的角色時,您必須擁有傳遞該角色到服務的許可。有些服務會自動在您在該服務中執行動作時,在您的帳戶中建立服務連結角色。例如,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 的 服務。若要了解服務是否為您自動建立服務連結角色,請選擇 Yes (是) 連結以檢視該服務的服務連結角色文件。

為何我無法擔任具 12 小時工作階段的角色? (AWS CLI、AWS API)

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

如果您使用角色鏈結 (使用角色來擔任第二個角色),則您的工作階段上限為一小時。如果您隨後使用 DurationSeconds 參數提供大於一小時的值,則操作會失敗。

當我嘗試在 IAM 主控台中切換角色時收到錯誤

您在 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 使用者政策可能會限制您的存取。您的管理員可以驗證這些政策的許可。

我的角色具有允許我執行動作的政策,但我收到「存取遭拒」

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

服務未建立角色的預設政策版本

服務角色是服務擔任的角色,以代表您在您的帳戶中執行動作。當您設定部分 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 無法運作,請清理並刪除現有的政策和角色。

如需編輯受管政策的詳細資訊,請參閱 編輯客戶受管政策 (主控台)。如需政策版本的詳細資訊,請參閱 版本控制 IAM 政策

刪除服務角色及其政策
  1. 登入 AWS Management Console,並開啟位於 https://console.aws.amazon.com/iam/ 的 IAM 主控台。

  2. 在導覽窗格上選擇 Policies (政策)

  3. 在政策清單中,選擇您要刪除的政策名稱。

  4. 選擇連接的實體索引標籤,可檢視哪些 IAM 使用者、群組或角色使用此政策。如果其中任一個身分使用政策,請完成下列任務:

    1. 建立具有必要許可的新受管政策。若要確保身分在您的動作之前和之後具有相同的許可,請從現有政策複製 JSON 政策文件。然後,建立新的受管政策並貼上 JSON 文件,如使用 JSON 編輯器建立政策所述。

    2. 對於每個受影響的身分,請連接新的政策,然後分開舊的政策。如需詳細資訊,請參閱新增和移除 IAM 身分許可

  5. 在導覽窗格中,選擇 Roles (角色)

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

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

    1. 建立新角色,這些角色信任那些實體。

    2. 您在上一個步驟中建立的政策。如果您略過了該步驟,請立即建立新的受管政策。

    3. 通知任何擔任該角色的人,他們不能再這樣做。為他們提供如何擔任新角色和具有相同許可的相關資訊。

  8. 刪除策略

  9. 刪除角色

主控台中沒有服務角色的使用案例

某些服務需要您手動建立服務角色,才能授與服務許可,以代表您執行動作。如果服務未列在 IAM 主控台中,您必須手動將服務列為受信任主體。如果您使用的服務或功能的文件不包含將服務列為受信任主體的說明,請提供頁面的意見回饋。

若要手動建立服務角色,您必須知道將擔任該角色之服務的服務主體。服務主體是用來將許可授與給服務的識別符。服務主體是由服務定義。

您可以檢查下列項目,找到某些服務的服務主體:

  1. 打開 AWS 使用 IAM 的 服務.

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

  3. 選擇連結,以檢視該服務的服務連結角色文件。

  4. 尋找該服務的 Service-Linked Role Permissions (服務連結角色許可) 區段,以檢視服務主體

您可以使用 AWS CLI 命令AWS API 操作手動建立服務角色。若要使用 IAM 主控台手動建立服務角色,請完成下列任務:

  1. 使用您的帳戶 ID 建立 IAM 角色。請勿連接政策或授與任何許可。如需詳細資訊,請參閱 建立角色以授予許可給 IAM 使用者

  2. 開啟角色並編輯信任關係。角色必須信任服務,而不是信任帳戶。例如,更新下列 Principal 元素:

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

    將主體變更為服務的值,例如 IAM。

    "Principal": { "Service": "iam.amazonaws.com" }
  3. 將許可政策連接至角色,以新增服務所需的許可。

  4. 返回需要許可的服務,並使用文件中描述的方法來通知服務有關新的服務角色。

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。