本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 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 會為您處理這些工作。您的外部使用者透過 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 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。
1. 在主控台的導覽窗格中，選擇 **Roles (角色)**，然後選擇 **Create role (建立角色)**。
1. 選擇 **AWS 帳戶** 角色類型。
1. 若要為您的帳戶建立角色，請選取 **This account** (此帳號)。若要為其他帳戶建立角色，請選擇 **Another AWS 帳戶** (另一個 )，然後輸入您要對其授予資源存取權的 **Account ID** (帳戶 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 身分驗證的使用者無法擔任角色。如需有關 MFA 的詳細資訊，請參閱 [AWS IAM 中的多重要素驗證](id_credentials_mfa.md)
1. 選擇**下一步**。
1. IAM 包含您帳戶中 AWS 受管和客戶受管政策的清單。選取用於許可政策的政策，或者選擇 **Create policy (建立政策)** 以開啟新的瀏覽器標籤，並從頭建立新的政策。如需詳細資訊，請參閱[建立 IAM 政策](access_policies_create-console.md#access_policies_create-start)。在您建立政策後，關閉該標籤並返回您的原始標籤。選取您希望擔任角色的任何人具有的許可政策旁的核取方塊。如果您希望，您目前可以不選取政策，稍後再將政策連接到角色。角色預設沒有任何許可。
1. (選用) 設定[許可界限](access_policies_boundaries.md)。這是進階功能。
開啟 **Set permissions boundary (設定許可界限)** 區段，並選擇 **Use a permissions boundary to control the maximum role permissions (使用許可界限來控制角色許可上限)**。選取用於許可界限的政策。
1. 選擇**下一步**。
1. 針對 **Role name (角色名稱)**，輸入您的角色名稱。角色名稱在您的 中必須是唯一的 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. 檢閱角色，然後選擇 **Create role** (建立角色)。
**重要**
請記住，這只是所需設定的前半部。您也必須以信任的帳戶許可提供給個別使用者，以切換到主控台中的角色，或程式化方式擔任角色。如需有關此步驟的詳細資訊，請參閱 [向使用者授予切換角色的許可](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 的詳細資訊，請參閱 [AWS IAM 中的多重要素驗證](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:` 磁碟機)。然後將先前的許可政策儲存為 中的客戶受管政策 AWS 帳戶 ，名稱為 `PolicyForRole`。然後，您可以使用以下命令來建立角色，並連接受管政策。
```
# 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)
如需有關在 中建立 IAM 角色的資訊 AWS CloudFormation，請參閱*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)。
如需 IAM 範本的詳細資訊 AWS CloudFormation，請參閱《 *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)。若要查看使用服務連結的角色支援哪些服務，或者服務是否支援任何形式的臨時憑證的詳細資訊，請參閱 [AWS 使用 IAM 的 服務](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 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 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. 檢閱角色，然後選擇 **Create role** (建立角色)。
------
## 為服務建立角色 (AWS CLI)
從 建立角色 AWS CLI 涉及多個步驟。當您使用 主控台建立角色時，會為您完成許多步驟，但您必須使用 自行 AWS CLI 明確執行每個步驟。您必須建立角色，然後為該角色指派許可政策。如果您使用的服務是 Amazon EC2，則還必須建立執行個體描述檔並新增該角色。或者，您也可以設定角色的[許可界限](access_policies_boundaries.md)。
**從 建立 AWS 服務的角色 AWS CLI**
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` 的許可政策儲存到您本機 `policies` 磁碟機的 `C:` 目錄。然後，您可以使用以下命令來建立角色、連接政策、建立執行個體設定檔，並新增角色到執行個體設定檔。
```
# 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 主控台，請在**設定執行個體詳細資訊頁面中指定執行個體**描述檔名稱。如果您使用 `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 實體。
在您刪除角色之前，您必須首先刪除它們的相關資源。這有助於防止不小心移除資源存取許可。
**提示**
如需哪些服務支援使用服務連結角色的資訊，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)，並尋找 **Service-Linked Role (服務連結角色)** 欄中顯示 **Yes (是)** 的服務。選擇具有連結的 **Yes (是)**，以檢視該服務的服務連結角色文件。
## 服務連結角色許可
您必須設定 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 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 手動建立服務連結角色。如需哪些服務支援使用服務連結角色的資訊，請參閱 [AWS 使用 IAM 的 服務](reference_aws-services-that-work-with-iam.md)，並尋找 **Service-Linked Role (服務連結角色)** 欄中顯示 **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 管理主控台 並開啟位於 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 的 IAM 主控台。
1. 在 IAM 主控台的導覽窗格中，選擇**角色**。然後，選擇 **Create role** (建立角色)。
1. 選擇 **AWS Service** (服務) 角色類型。
1. 選擇服務的使用案例。服務會定義使用案例，以包含服務所需的信任政策。然後選擇**下一步**。
1. 選擇一或多個許可政策以連接至角色。根據您選取的使用案例，服務可能可以執行下列任何操作：
+ 定義角色使用的許可。
+ 可讓您從有限的一組許可中進行選擇。
+ 可讓您從任何許可中進行選擇。
+ 可讓您目前無法選取政策、稍後建立政策，然後將它們連接至角色。
選取可指派您希望角色擁有之許可政策旁的核取方塊，然後選擇**下一步**。
**注意**
您指定的許可適用於任何使用角色的實體。角色預設沒有任何許可。
1. 針對 **Role name (角色名稱)**，服務會定義角色名稱自訂程度。如果服務定義角色的名稱，則此選項無法編輯。在其他情況下，服務可能會定義角色的字首，並且允許您輸入選用後綴。
如果可能，輸入要新增至預設名稱的角色名稱後綴。此後綴可協助您識別此角色的用途。角色名稱在您的 AWS 帳戶內必須是獨一無二的。它們無法透過大小寫進行區分。例如，您無法建立名為 **\$1SAMPLE** 和 **\$1sample** 的角色。因為有各種實體可能會參照角色，所以您無法在建立角色之後編輯角色名稱。
1. (選用) 在 **Description** (說明) 中，編輯新服務連結角色的說明。
1. 您不能在建立角色時，將標籤連接至服務連結的角色。如需有關在 IAM 中使用標籤的詳細資訊，請參閱 [AWS Identity and Access Management 資源的標籤](id_tags.md)。
1. 檢閱角色，然後選擇 **Create role** (建立角色)。
### 建立服務連結角色 (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`。
# 為第三方身分提供者建立角色
您可以使用身分提供者，而不是在 中建立 IAM 使用者 AWS 帳戶。使用身分提供者 (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 Identity and Access Management 使用者 AWS 帳戶。使用身分提供者 (IdP)，您可以在 外部管理您的使用者身分， AWS 並授予這些外部使用者身分存取 AWS 您帳戶中資源的許可。如需有關聯合身分與 IdP 的詳細資訊，請參閱 [身分提供者和聯合身分 AWS](id_roles_providers.md)。
## 建立適用於 OIDC 的角色的先決條件
您必須先完成以下先決條件步驟，然後才能建立用於 OIDC 聯合身分的角色。
**若要準備建立用於 OIDC 聯合身分的角色**
1. 使用一或多個提供聯合 OIDC 身分的服務進行註冊。如果您要建立需要存取 AWS 資源的應用程式，您也可以使用提供者資訊來設定應用程式。當您這麼做時，提供者會將應用程式唯一的 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 身分提供者，我們建議您使用 [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"}
}
}
}
```
------
以 Amazon Cognito 指派給您的身分集區 ID 取代 `us-east-2:12345678-abcd-abcd-abcd-123456`。
如果您手動設定 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 身分提供者的 Amazon Resource Name (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 Developer Guide* 中的 [Trust policies for IAM roles in Basic (Classic) authentication](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 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。
1. 在導覽窗格中，選擇 **Roles** (角色)，然後選擇 **Create role** (建立角色)。
1. 選擇 **Web 身分**作為信任的實體類型，然後選取**下一步**。
1. 針對 **Identity provider** (身分提供者)，選擇您角色的身分提供者：
+ 如果要為個別 Web 身分提供者建立角色，請選擇 **Login with Amazon**、**Facebook** 或 **Google**。
**注意**
您必須為想要支援的每個身分提供者建立單獨的角色。
+ 如果想要為 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 Actions 建立角色，您必須先將 GitHub OIDC 提供者新增至 IAM。將 GitHub OIDC 提供者新增至 IAM 之後，請選擇 **token.actions.githubusercontent.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 建立角色，請將應用程式 ID 輸入 **Application ID** (應用程式 ID) 方塊中。
+ 如果您要為 Facebook 建立角色，請將應用程式 ID 輸入 **Application 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. 檢閱角色，然後選擇 **Create role** (建立角色)。
## 設定 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 的 *Using environments for deployment* 文章中的 [Deployment branches and tags](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 和 ?) 或 null。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 聯合，而不是在 中建立 IAM 使用者。 AWS 帳戶使用身分提供者 (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 聯合身分的角色含有兩項政策。其中一項是角色信任政策，指定擔任該角色的對象。另一個是 IAM 許可政策，指定允許或拒絕 SAML 聯合主體存取 AWS 的動作和資源。
當您為您的角色建立信任政策時，必須使用三個值，以確保只有您的應用程式可擔任該角色：
+ 對於 `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 收件人屬性。您可以在特定區域中包含登入 URLs。 AWS 建議使用區域端點而非全域端點來改善聯合彈性。對於可能的 *region-code* 值清單，請參閱 [AWS 登入端點](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)中的 **Region** (區域) 欄位。
如果需要 SAML 加密，登入 URL 必須包含指派給 SAML 提供者的唯一識別碼 AWS 。可以透過在 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 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 IAM 主控台。
1. 在 IAM 主控台的導覽窗格中，選擇 **Roles** (角色)，然後選擇 **Create role** (建立角色)。
1. 選擇 **SAML 2.0 federation (SAML 2.0 聯合身分)** 角色類型。
1. 針對 **Select a SAML provider** (選擇 SAML 提供者)，選擇您角色的提供者。
1. 選擇 SAML 2.0 存取層級的方法。
+ 選擇**僅允許程式設計存取**，以建立可從 AWS API 或 以程式設計方式擔任的角色 AWS CLI。
+ 選擇**允許程式設計和 AWS 管理主控台 存取**，以建立可以程式設計方式從 擔任的角色 AWS 管理主控台。
同時建立類似的角色，但也可以從主控台所擔任的角色包括具有特定條件的信任政策。該條件明確確保可將 SAML 對象 (`SAML:aud` 屬性) 設定為 SAML 提供者的 AWS 登入端點。
1. 定義屬性的程序因存取類型而異。
+ 如果要為程式設計存取建立角色，請從 **Attribute (屬性)** 清單選取屬性。然後，在 **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. 若要**讓登入 URLs 包含唯一識別符**，請選取登入端點是否包含 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. 檢閱角色，然後選擇 **Create role** (建立角色)。
在您建立角色之後，您透過 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 管理主控台 ，並在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 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. 針對 **Role name (角色名稱)**，服務會定義角色名稱自訂程度。如果服務定義角色名稱，則無法編輯此選項。在其他情況下，服務可能會定義角色的字首，並且可允許您輸入選用後綴。有些服務可讓您指定角色的完整名稱。
如有可能，請輸入角色名稱或角色名稱後綴。角色名稱在您的 中必須是唯一的 AWS 帳戶。它們不區分大小寫。例如，您無法建立名為 **PRODROLE** 和 **prodrole** 的角色。由於其他 AWS 資源可能會參考角色，因此您無法在建立角色之後編輯角色的名稱。
1. (選用) 在 **Description** (說明) 中，輸入新角色的說明。
1. (選用) 在**步驟 1：選取信任的實體**或**步驟 2：新增許可**區段中選擇**編輯**，以編輯角色的自訂政策和許可。
1. (選用) 藉由連接標籤作為鍵值對，將中繼資料新增至角色。如需有關在 IAM 中使用標籤的詳細資訊，請參閱 [AWS Identity and Access Management 資源的標籤](id_tags.md)。
1. 檢閱角色，然後選擇 **Create role** (建立角色)。
# 委派存取權限的政策範例
下列範例示範如何允許或授予 AWS 帳戶 存取另一個 中的資源 AWS 帳戶。若要了解如何使用這些範例 JSON 政策文件來建立 IAM 政策，請參閱 [正在使用 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。當您儲存政策時， 會將 ARN AWS 轉換為唯一的委託人 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 授予許可，以對帳戶 A 中名為 *queue1* 的佇列執行 `SendMessage` 和 `ReceiveMessage` 動作，但只能在 2014 年 11 月 30 日中午 12:00 至下午 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))。
帳戶 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 儲存貯體存取許可的政策。