ある開発チームはGitHub.com（クラウドホスト型）のGitHub Actionsを使用してAWSにアプリケーションをデプロイしています。現在はIAMユーザーのアクセスキーをGitHub Secretsに保存していますが、セキュリティチームから「長期認証情報の使用をやめ、短期認証情報のみでAWSリソースにアクセスするよう」指摘されました。AWSアカウント側の構成変更を最小限に抑えながら長期認証情報なしでAWSリソースにアクセスする最も適切な方法はどれですか？
GitHub ActionsはOIDC（OpenID Connect）プロバイダーとして機能し、各ジョブ実行時に署名済みのOIDCトークンを発行します。AWSにIAM OIDCプロバイダーとしてtoken.actions.githubusercontent.comを登録し、IAMロールの信頼ポリシーでトークンのsub（リポジトリ名やブランチ名）を条件としてフィルタリングすることで、特定のリポジトリ・ブランチからのみAssumeRoleWithWebIdentityを許可できます。長期認証情報は一切不要で、ワークフローのたびに短期の一時認証情報のみを使用するため安全です。 選択肢AのIAMユーザーのアクセスキーをAWS Secrets Managerに保存し、GitHub ActionsワークフローからSecrets Manager APIを呼び出して動的にキーを取得してからAWS CLIを実行する方法は、GitHub ActionsがSecrets Manager APIを呼ぶための初期認証情報が別途必要となり、長期認証情報の課題は根本的に解決されません（鶏と卵の問題）。 選択肢BのAWS IAM Identity Centerでサービスアカウントを作成し、SAML 2.0フェデレーションを使用してGitHub ActionsからIAM Identity Centerに認証し、一時認証情報を取得する方法はブラウザリダイレクトを前提とするインタラクティブなフローであり、CI/CDパイプラインのような非インタラクティブな自動化環境での利用には適していません。 選択肢DのGitHub Actionsのself-hostedランナーをEC2インスタンス上に構築し、EC2インスタンスプロファイルのIAMロールを使用してAWSリソースにアクセスする方法も長期認証情報を排除できる有効な方法ですが、EC2インスタンスの維持・管理コストが発生します。問題文はクラウドホスト型ランナーを前提としており、インフラ追加なしに実現できるOIDCアプローチがより直接的で最適です。