AZ-305：Designing Microsoft Azure Infrastructure Solutions ID・ガバナンス・監視ソリューションの設計 問10
ID・ガバナンス・監視ソリューションの設計／認証と認可ソリューションの設計ある企業は、GitHub のリポジトリから GitHub ホステッド ランナーで実行する GitHub Actions のワークフローで、特定のリソース グループに Bicep をデプロイします。要件は、GitHub 側に Azure の資格情報（シークレットや証明書）を保存しないこと、資格情報の有効期限切れによるパイプライン停止の運用を発生させないこと、本番へのデプロイを GitHub の特定の環境（Production）で実行されたワークフローに限定すること、権限は対象のリソース グループに必要最小限とすることです。認証と認可の設計として最適なものはどれですか。
当サイトのオリジナル問題（AZ-305：Designing Microsoft Azure Infrastructure Solutionsの出題範囲「ID・ガバナンス・監視ソリューションの設計」に対応。実際の試験問題ではありません）
- Aアプリ登録のサービスプリンシパルにクライアント シークレットを発行して GitHub のシークレットに保存し、有効期限が切れる前に更新する運用を定めて、サブスクリプションの共同作成者ロールを割り当てる
- Bアプリ登録のサービスプリンシパルに証明書を発行して GitHub の環境シークレットに保存し、Production 環境に承認者を設定して、対象のリソース グループに共同作成者ロールを割り当てる
- Cユーザー割り当てマネージド ID に、発行者を GitHub、サブジェクトを Production 環境に限定したフェデレーション ID 資格情報を構成し、対象のリソース グループに必要なロールだけを割り当てる
- DAzure 仮想マシンにセルフホステッド ランナーを構築してシステム割り当てマネージド ID を有効にし、ワークフローをその仮想マシンで実行して、対象のリソース グループに必要なロールを割り当てる
正解：C
解説
Azure の外で動く GitHub Actions などのワークロードが、シークレットなしで Azure に認証するには、ワークロード ID フェデレーションを使います。ユーザー割り当てマネージド ID（またはアプリ登録）にフェデレーション ID 資格情報を構成し、GitHub が発行する OIDC トークンの発行者とサブジェクト（リポジトリや環境など）を信頼する条件を指定すると、条件に合うワークフローだけが短期のトークンで認証できます。保存する資格情報がないため有効期限切れや漏えいの問題がなく、サブジェクトを Production 環境に絞ることで要件も満たせます。認可は、対象のリソース グループに必要最小限のロールだけを割り当てます。
選択肢ごとの解説
- A誤り。クライアント シークレットは GitHub 側に保存する資格情報であり、有効期限の管理と更新が必要になります。サブスクリプション全体への共同作成者ロールは最小権限にも反します。
- B誤り。証明書も GitHub 側に保存する資格情報で、有効期限の管理と更新が必要です。環境の承認者を設定しても、保存した資格情報を持つ点は変わらず、要件に反します。
- C正しい。フェデレーション ID 資格情報により、GitHub のトークンを信頼して資格情報を保存せずに認証でき、サブジェクトで Production 環境に限定し、リソース グループ スコープの最小権限で割り当てられます。
- D誤り。仮想マシンのシステム割り当てマネージド ID では、その仮想マシンで動くすべてのワークフローが同じ権限を得てしまい、Production 環境で実行されたワークフローだけに限定できません。セルフホステッド ランナーの構築・運用や保守負担も増え、GitHub ホステッド ランナーで実行する前提からも外れます。