おはようございます。YASUです。
ポートフォリオサイトのGitHubリポジトリ、実は名前がずっと紛らわしいままでした。「aws-bedrock-chatbot」という名前なのに、中身はチャットボットだけでなくポートフォリオサイト全体を管理している、という状態です。整理のために名前を変えただけのはずが、思わぬところでデプロイが壊れてしまいました。
結論
リポジトリ名を変更したら、GitHub Actionsの自動デプロイが、突然「認証エラー」で失敗するようになりました。原因は、GitHubが「なりすまし防止」のために、リネーム後のリポジトリには内部的なIDを含んだ、少し特殊な形式の証明書を発行するようになっていたことでした。
まず、名前を変えただけのつもりだった
フォルダ名(`yasu-portfolio`)と、GitHub上のリポジトリ名(`aws-bedrock-chatbot`)が食い違っていて、地味に混乱の元になっていました。GitHubの設定画面から、リポジトリ名を`yasu-portfolio`に変更するのは、ものの数秒で終わる作業です。
ところが、その直後にポートフォリオサイトを更新してプッシュしたところ、いつもは自動で反映されるはずのサイトが、更新されなくなっていました。
GitHub Actionsを見てみると、認証エラー
GitHubのActionsタブを開くと、赤い×マークで失敗の表示。中身を見ると、こんなエラーが出ていました。
Could not assume role with OIDC: Not authorized to perform sts:AssumeRoleWithWebIdentity
「認証しようとしたけど、許可されなかった」という内容です。以前構築した、GitHub ActionsからAWSへの自動デプロイの仕組み(OIDCという、長期的な鍵を保存しない安全な認証方式)が、突然うまく動かなくなっていました。
一度直したはずが、また同じエラー
まず疑ったのは、AWS側のIAMロール(権限のかたまり)が、「リポジトリ名が変わったこと」に対応できていないんじゃないか、という点でした。実際、権限の設定を確認すると、古いリポジトリ名(`aws-bedrock-chatbot`)のままになっていたので、新しい名前(`yasu-portfolio`)に修正しました。
ところが、再度実行しても、まったく同じエラー。名前を直したはずなのに、なぜか許可されない。ここで一段深く、原因を調査することになりました。
原因は、AWSの操作ログの中にあった
AWSには、CloudTrailという、すべての操作を記録しているログがあります。これを直接確認したところ、実際にGitHubから送られてきていた認証情報の中身が、想定していたものと違うことが分かりました。
想定していた形式はこうです。
repo:yasutomo7974/yasu-portfolio:ref:refs/heads/main
でも、実際に送られてきていたのは、こういう形式でした。
repo:yasutomo7974@208730822/yasu-portfolio@1221414810:ref:refs/heads/main
組織名やリポジトリ名の後ろに、見慣れない数字の羅列(`@208730822`など)がくっついています。
「なりすまし防止」のための、内部ID
調べてみると、これはGitHub側の意図的な仕様でした。リポジトリの名前は変更できますが、変更後に同じ名前を第三者が新しく作り直せてしまう可能性があります。もしそれを許してしまうと、過去に信頼されていた名前を悪用して、なりすましができてしまうことになります。
それを防ぐために、GitHubはリポジトリがリネームされた場合、単純な名前ではなく、組織・リポジトリそれぞれに紐づく、変わらない内部IDを含んだ形式で証明書を発行するようになっているようでした。
実際のログの値に合わせて、信頼関係を直す
原因が分かれば、対処は単純でした。AWS側の信頼設定(どんな証明書なら信頼するかのルール)を、実際に送られてきていた形式に合わせて更新するだけです。
修正後、GitHub Actionsを再実行したところ、無事に成功。CloudTrailのログでも、認証が正常に完了していることを確認できました。
今回の学び
- GitHubのリポジトリ名を変更すると、OIDC認証で使われる証明書の中身が変わることがある
- これはGitHubが「なりすまし防止」のために、内部IDを付与する仕様によるもの
- AWSのCloudTrailログを見れば、実際に送られてきている証明書の中身を確認できる
- 信頼設定は、想定ではなく、実際のログの値に合わせて直すのが確実
まとめ
単純に名前を整理しただけのつもりが、思わぬ副作用でデプロイが止まる、という良い経験になりました。原因がすぐには分からず、何度か同じエラーにぶつかりましたが、最終的にはログを見て、実際の値に基づいて直す、という王道の解決方法にたどり着けました。名前を変えるだけでも、裏側では色々な仕組みが動いているのだと実感した一日でした。
それでは、また次の記事で。

コメント