ID プロバイダーで発生する、IAM の「AccessDenied」または「AssumeRoleWithWebIdentity を実行する権限がありません」というフェデレーションエラーのトラブルシューティング方法を教えてください。

所要時間2分

AWS Identity and Access Management (IAM) ポリシーまたはロールを、ID プロバイダー (IdP) からのフェデレーションで使用しました。「AccessDenied」または「AssumeRoleWithWebIdentity が許可されていません」というエラーが発生しました。

簡単な説明

API アクションAssumeRoleWithWebIdentity で発生するエラーの原因は、IAM 信頼ポリシーまたは、IdP の IAM ロールが正しく設定されていないことです。

解決策

この問題を解決するには、指示に従って OpenID Connect (OIDC) フェデレーション用の IAM ロールを作成してください。次に、以下のガイドラインに従って IAM ロールの信頼ポリシーを設定します。

**注:**AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI エラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

IAM ロールの信頼ポリシー

IAM ロールの信頼ポリシーが IdP 用に正しく設定されていることを確認します。

GitHub IdP 用のロールトラストポリシーの例

{
  "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"
        }
      }
    }
  ]
}

IAM ロール設定

IAM ロールが IdP の正しい Amazon リソースネーム (ARN) で設定されていることを確認します。IAM ロールを設定する手順は、IdP や AWS サービスによって異なります。

たとえば、Amazon Elastic Kubernetes サービス (Amazon EKS) のサービスアカウントの IAM ロール ARN を取得するには、次のコマンドを実行します。

kubectl describe serviceaccount serviceaccount_name -n namespace_name

出力を参照し、IAM ロールの ARN が引き受ける対象であることを確認します。IAM ロールの ARN が正しい場合は、手順に従って IAM ロールを Kubernetes サービスアカウントに割り当てます。IAM ロールの ARN が正しくない場合は、「ロールを作成し、関連付ける」の手順に従って ARN を更新してください。

詳細については、「クラスター用の IAM OIDC プロバイダーを作成する」を参照してください。

CloudTrail イベント履歴

API アクション AssumeRoleWithWebIdentity のエラーは、AWS CloudTrail イベント履歴に記録されます。過去 90 日間の、サポートされているすべてのサービスと統合、およびイベントタイプ (作成、変更、削除、変更不可能なアクティビティなど) を確認できます。CloudTrail イベント履歴を使用するために証跡を設定する必要はありません。

ロールの信頼ポリシーの CloudTrail イベント履歴に記録されている PrincipalId 値を比較して、API リクエストで渡された値を確認します。

たとえば、arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com:sts.amazonaws.com:repo:reponame-rn/new-repo:environment:dev という値が CloudTrail イベントの PrincipalId に記録されている場合は、次の信頼ポリシーを使用します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012: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:reponame-rn/new-repo:environment:dev"
        }
      }
    }
  ]
}

詳細については、「コンソールで最近の管理イベントを確認する」を参照してください。

構成のベストプラクティス

構成の問題をトラブルシューティングするには、次のベストプラクティスに従ってください。

ロール信頼ポリシーのプリンシパル ARN が完全ではない: 信頼ポリシーのフェデレーションプリンシパル ARN には、完全な ARN と OIDC プロバイダー名が必要です。たとえば、GitHub IdP を使用している場合、プリンシパル ARN は arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com という形式です。
ARN のパーティションが誤っている: ARN 設定には、ロールと OIDC プロバイダー用の正しいパーティションが必要です。たとえば、AWS GovCloud パーティション内の OIDC プロバイダーの ARN は、arn:aws-us-gov:iam::123456789012:oidc-provider/token.actions.githubusercontent.com という形式です。
条件キーが使用できない: IdP には、OIDC フェデレーションで利用できる条件キーと互換性がないものもあります。条件キーと OIDC プロバイダーとの互換性を必ず確認してください。詳細については、「AWS OIDC フェデレーションで使用できるキー」を参照してください。
IdP 設定でロールパスが欠けている: IdP には、完全な IAM ロールと ARN パスを設定する必要があります。たとえば、administrator パス ARN にある IAM ロール名 GitHubRole は、arn:aws:iam::123456789012:role/administrator/GitHubRole という構成です。