ロールを引き受けることができない AWS アカウントに新しいロールが表示される自分の AWS アカウントでロールを編集または削除できない次のことを実行する権限がない: iam:PassRole 12 時間のセッションに使用するロールを引き受けることができない (AWS CLI、AWS API)IAM コンソールでロールを切り替えようとするとエラーが発生するロールには、アクションの実行を許可するポリシーがあるが、「アクセスが拒否されました」というメッセージが表示されるサービスがロールのデフォルトのポリシーバージョンを作成しなかったコンソールにサービスロールのユースケースがない

IAM ロールのトラブルシューティング

この情報を使用して、IAM ロールを操作するときに発生する可能性がある一般的な問題の診断や修復を行います。

トピック

ロールを引き受けることができない
AWS アカウントに新しいロールが表示される
自分の AWS アカウントでロールを編集または削除できない
次のことを実行する権限がない: iam:PassRole
12 時間のセッションに使用するロールを引き受けることができない (AWS CLI、AWS API)
IAM コンソールでロールを切り替えようとするとエラーが発生する
ロールには、アクションの実行を許可するポリシーがあるが、「アクセスが拒否されました」というメッセージが表示される
サービスがロールのデフォルトのポリシーバージョンを作成しなかった
コンソールにサービスロールのユースケースがない

ロールを引き受けることができない

以下をチェックしてください:

ロールセッション内でユーザーが現在のロールを再び引き受けることができるようにするには、ロール信頼ポリシーでロール ARN または AWS アカウント ARN をプリンシパルとして指定します。Amazon EC2、Amazon ECS、Amazon EKS、Lambda などのコンピューティングリソースを提供する AWS のサービスは、一時的な認証情報を提供し、これらの認証情報を自動的に更新します。これにより、常に有効な認証情報セットを確保できます。これらのサービスでは、一時的な認証情報を取得するために現在のロールを再度引き受ける必要はありません。ただし、セッションタグまたはセッションポリシーを渡す場合は、現在のロールを再度引き受ける必要があります。ロールの信頼ポリシーを変更してプリンシパルロールの ARN または AWS アカウント ARN を追加する方法については、ロールの信頼ポリシーの変更 (コンソール) を参照してください。
AWS Management Console を使用してロールを引き受ける場合は、必ずロールの正確な名前を使用してください。ロール名では、ロールを引き受けるときに、大文字と小文字が区別されます。
AWS STS API または AWS CLI を使用してロールを引き受ける場合は、必ず ARN のロールの正確な名前を使用してください。ロール名では、ロールを引き受けるときに、大文字と小文字が区別されます。
IAM ポリシーによって、引き受けるロールの sts:AssumeRole を呼び出すアクセス許可が付与されていることを確認します。IAM ポリシーの Action 要素で、AssumeRole アクションの呼び出しを許可する必要があります。さらに、IAM ポリシーの Resource 要素で、引き受けるロールを指定する必要があります。たとえば、Resource エレメントでは Amazon リソースネーム (ARN) またはワイルドカード (*) で、ロールを指定できます。たとえば、ユーザーに該当する 1 つ以上のポリシーで、以下のようなアクセス許可を付与する必要があります。
```
    "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 ユーザーおよびロールのタグ付けについては、「IAM リソースのタグ付け」を参照してください。
```
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "*",
    "Condition": {"StringEquals": {"aws:PrincipalTag/department": [
            "HR",
            "CS"
        ]}}
```
ロールの信頼ポリシーで指定されているすべての条件が満たされていることを確認します。1 つの 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 として定義されます。次の例は、引き受けるロールにアタッチされている信頼ポリシーです。この例の場合、サインインに使用した 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"}
    }
```
ソース ID — 管理者は、ソース IDと呼ばれる AWS でアクションを実行している個人またはアプリケーションを識別するカスタム文字列を渡すように ID を要求するようにロールを構成できます。引き受けるロールがソース ID を設定する必要があるかどうかを確認します。ソース ID の詳細については、「引き受けたロールで実行されるアクションのモニタリングと制御」を参照してください。

AWS アカウントに新しいロールが表示される

一部の AWS のサービスでは、サービスに直接リンクされた一意のタイプのサービスロールを使用する必要があります。このサービスにリンクされたロールはサービスによって事前に定義され、サービスで必要なすべてのアクセス許可が含まれます。これにより、必要なアクセス許可を手動で追加する必要がなくなるため、サービスの設定が簡単になります。サービスにリンクされたロールの一般情報については、「サービスリンクロールの使用」を参照してください。

サービスにリンクされたロールのサポートを開始するときに、既にサービスを使用している可能性があります。その場合、アカウントに新しいロールについて伝える E メールが届くことがあります。このロールには、サービスがお客様に代わってアクションを実行するために必要なすべてのアクセス権限が含まれています。このロールをサポートするために、お客様が実行する必要があるアクションはありません。ただし、アカウントからロールを削除しないでください。ロールを削除すると、サービスが AWS リソースにアクセスするために必要なアクセス許可が削除される可能性があります。アカウントのサービスにリンクされたロールを表示するには、IAM コンソールの IAM ロールページに移動します。サービスにリンクされたロールが、テーブルの [Trusted entities] (信頼されたエンティティ) 列の [(Service-linked role)] ((サービスにリンクされたロール)) に表示されます。

サービスにリンクされたロールをサポートするサービスについては、「IAM と連携する AWS のサービス」を参照してください。これらのサービスでは、[Service-Linked Role] (サービスにリンクされたロール) 列が、[Yes] (はい) になっています。サービスにリンクされたロールをサービスで使用するには、[Yes (はい)] リンクを選択します。

自分の AWS アカウントでロールを編集または削除できない

IAM の「サービスにリンクされたロール」のアクセス許可を削除または編集することはできません。これらのロールには、サービスがお客様に代わってアクションを実行するために必要な事前定義された信頼とアクセス許可が含まれます。サービスにリンクされたロールの説明は、IAM コンソール、AWS CLI、API のいずれかでのみ編集できます。アカウントのサービスにリンクされたロールを表示するには、コンソールの IAM ロール ページに移動します。サービスにリンクされたロールが、テーブルの [Trusted entities] (信頼されたエンティティ) 列の [(Service-linked role)] ((サービスにリンクされたロール)) に表示されます。ロールの [Summary (概要)] ページのバナーにも、そのロールがサービスにリンクされたロールであることが示されています。サービスでアクションがサポートされている場合、リンクされたサービスを通じてのみこれらのロールを管理および削除できます。サービスにリンクされたロールを変更または削除すると、サービスが AWS リソースにアクセスするために必要なアクセス許可が削除される可能性があるので、注意してください。

サービスにリンクされたロールをサポートするサービスについては、「IAM と連携する AWS のサービス」を参照してください。これらのサービスでは、[Service-Linked Role] (サービスにリンクされたロール) 列が、[Yes] (はい) になっています。

次のことを実行する権限がない: iam:PassRole

リンクされたサービスロールを作成する場合、サービスにそのロールを渡す権限を持っている必要があります。一部のサービスでは、そのサービスでアクションを実行する際にアカウント内にサービスにリンクされたロールが自動的に作成されます。たとえば Amazon EC2 Auto Scaling では、Auto Scaling グループを初めて作成すると、サービスにリンクされたロール AWSServiceRoleForAutoScaling が作成されます。PassRole アクセス許可がない状態で Auto Scaling グループを作成しようとすると、以下のようなエラーが表示されます。

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 と連携する AWS のサービス」を参照してください。サービスにリンクされたロールをサービスで作成できるかどうかを確認するには、[はい] リンクを選択して、該当サービスのサービスにリンクされたロールに関するドキュメントを確認します。

12 時間のセッションに使用するロールを引き受けることができない (AWS CLI、AWS API)

AWS STS AssumeRole* API または assume-role* CLI オペレーションを使用してロールを引き受ける場合は、DurationSeconds パラメータの値を指定できます。900 秒 (15 分) からロールの最大セッション期間設定までの値を指定できます。この設定よりも高い値を指定した場合、オペレーションは失敗します。この設定の最大値は 12 時間です。たとえば、12 時間のセッションの期間を指定したが、管理者が最大のセッション期間を 6 時間に設定した場合、オペレーションは失敗します。ロールの最大値を確認する方法については、「ロールの最大セッション期間設定の表示」を参照してください。

ロールの連鎖 (ロールを使用して 2 つ目のロールを引き受ける) を使用している場合、セッションは最大 1 時間に制限されます。この場合 DurationSeconds パラメータを使用して 1 時間より大きい値を指定すると、オペレーションは失敗します。

IAM コンソールでロールを切り替えようとするとエラーが発生する

[ロールの切り替え] ページに入力する情報は、ロールの情報と一致している必要があります。そうでない場合は、オペレーションは失敗し、次のエラーが表示されます。

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

このエラーが表示された場合は、次の情報が正しいことを確認します。

アカウント ID またはエイリアス - AWS アカウント ID は 12 桁の数字です。アカウントには、AWS アカウント ID の代わりに使用できる会社名などのわかりやすい識別子であるエイリアスがある場合があります。このフィールドでは、アカウント ID またはエイリアスのいずれかを使用できます。
ロール名 – ロール名では、大文字と小文字が区別されます。アカウント ID とロール名は、ロールに対して設定されているものと一致する必要があります。

引き続きエラーメッセージが表示される場合は、管理者に問い合わせて、以前の情報を確認してください。ロールの信頼ポリシーまたは IAM ユーザーポリシーによって、アクセスが制限される場合があります。管理者は、これらのポリシーのアクセス許可を確認できます。

ロールには、アクションの実行を許可するポリシーがあるが、「アクセスが拒否されました」というメッセージが表示される

ロールセッションはセッションポリシーによって制限される場合があります。AWS STS を使用してプログラムで一時的なセキュリティ認証情報をリクエストする場合は、オプションでインラインまたは管理セッションポリシーを渡すことができます。セッションポリシーは、ロールの一時認証情報セッションをプログラムで作成する際にパラメータとして渡す高度なポリシーです。Policy パラメータを使用して単一の JSON インラインセッションポリシードキュメントを渡すことができます。PolicyArns パラメータを使用して、最大 10 個の管理セッションポリシーを指定できます。結果として得られるセッションのアクセス許可は、ロールの ID ベースのポリシーとセッションポリシーの共通部分です。または、管理者またはカスタムプログラムから一時的な認証情報が提供されている場合は、アクセスを制限するためのセッションポリシーが含まれている可能性があります。

サービスがロールのデフォルトのポリシーバージョンを作成しなかった

サービスロールは、サービスがお客様に代わってお客様のアカウントでアクションを実行するために引き受けるロールです。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 ポリシーのバージョニング」を参照してください。

サービスロールとそのポリシーを削除するには

AWS Management Console にサインインして、IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。
ナビゲーションペインで、[ポリシー] を選択します。
ポリシーの一覧で、削除するポリシーの名前を選択します。
[アタッチされたエンティティ] タブを選択して、このポリシーを使用する IAM ユーザー、グループ、またはロールを表示します。これらの ID のいずれかがポリシーを使用する場合は、次のタスクを実行します。
1. 必要なアクセス許可を持つ新しい管理ポリシーを作成します。アクションの前後に ID が同じアクセス許可を持つようにするには、既存のポリシーから JSON ポリシードキュメントをコピーします。次に、新しい管理ポリシーを作成し、JSON エディタを使用したポリシーの作成の説明に従って JSON ドキュメントを貼り付けます。
2. 影響を受ける ID ごとに、新しいポリシーをアタッチしてから、古いポリシーをデタッチします。詳細については、「IAM ID のアクセス許可の追加および削除」を参照してください。
ナビゲーションペインで Roles (ロール) を選択します。
ロールのリストで、削除するロールの名前を選択します。
[信頼関係] タブを選択して、ロールを引き受けることができるエンティティを表示します。サービス以外のエンティティが一覧表示されている場合は、次のタスクを実行します。
1. これらのエンティティを信頼する新しいロールを作成します。
2. 前のステップで作成したポリシー。このステップを省略した場合は、新しい管理ポリシーをここで作成します。
3. ロールを引き受けていたすべてのユーザーに、もう実行できないことを通知します。新しいロールを引き受ける方法と、同じアクセス許可を持つ方法に関する情報を提供します。
ポリシーを削除します。
ロールを削除します。

コンソールにサービスロールのユースケースがない

一部のサービスでは、お客様に代わってアクションを実行するサービスアクセス許可を付与するために、サービスロールを手動で作成する必要があります。サービスが IAM コンソールに表示されない場合は、信頼されたプリンシパルとしてサービスを手動で一覧表示する必要があります。使用しているサービスまたは機能のドキュメントに、信頼されたプリンシパルとしてサービスを一覧表示する手順が含まれていない場合は、ページについてのフィードバックを提供します。

サービスロールを手動で作成するには、そのロールを引き受けるサービスのサービスプリンシパルを知っている必要があります。サービスプリンシパルは、サービスにアクセス許可を付与するために使用される識別子です。サービスプリンシパルはサービスによって定義されます。

次の項目を確認することで、一部のサービスのサービスプリンシパルを検索できます。

IAM と連携する AWS のサービスを開きます。
サービスの [Service-linked roles] (サービスにリンクされたロール) 列に [Yes] (はい) が表示されているかどうかを確認します。
サービスにリンクされたロールに関するドキュメントをサービスで表示するには、[Yes] リンクを選択します。
サービスプリンシパルを表示するには、そのサービスの [Service-Linked Role Permissions] (サービスにリンクされたロールのアクセス許可) のセクションを探します。

AWS CLI コマンドまたは AWS API オペレーションを使用して、サービスロールを手動で作成できます。IAM コンソールを使用してサービスロールを手動で作成するには、次のタスクを実行します。

アカウント ID を使用して IAM ロールを作成します。ポリシーをアタッチしたり、アクセス許可を付与したりしないでください。詳細については、「IAM ユーザーにアクセス許可を委任するロールの作成」を参照してください。
ロールを開き、信頼関係を編集します。ロールはアカウントを信頼する代わりに、サービスを信頼する必要があります。例えば、次の Principal 要素を更新します。
```
"Principal": { "AWS": "arn:aws:iam::123456789012:root" }
```
プリンシパルをサービスの値 ( IAM など) に変更します。
```
"Principal": { "Service": "iam.amazonaws.com" }
```
アクセス許可ポリシーをロールにアタッチして、サービスが必要とするアクセス許可を追加します。
アクセス許可を必要とするサービスに戻り、文書化されたメソッドを使用して、新しいサービスロールについてサービスに通知します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

FIDO セキュリティキー

IAM および Amazon EC2