GitHub ActionsとAWSのOIDC連携について理解を整理
先日GitHub Actionsが提供しているID Providerの証明書が変更されて、AWSに設定されているthumbprintがマッチしなくなり、AWSへOIDC経由でアクセスしているActionsのworkflowがエラーになる事象が起きた。
どうすればこの問題を回避できるかはわかったんだけど、そもそもGitHub ActionsとAWSのOIDC連携についての理解が浅くてどこでなんの問題が起こって、何を解決すると治るのかよくわからなかったので理解を整理してみる。
自分でかんがえまとめてるだけなので、間違いがあるかもで、間違いに気づいたら適宜更新します。
GitHub Actionsの多くのworkflowはAWS, Azure, GCPなどのクラウドプロバイダーへデプロイなどを実施するためにアクセスすることがある
Actionsのworkflowは認証情報(passwordやtoken)をクラウドプロバイダーに渡すことで、デプロイなどを実施できる
これらの認証情報は通常GitHubのシークレットとして保存しておく必要がある
OIDCを使うとクラウドプロバイダーから有効期間の短いアクセストークンを発行してもらうことで、別のアプローチでActionsのワークフローを動かすことができる
OIDCでクラウドプロバイダーに接続するためには、クラウドプロバイダー側もOIDCに対応している必要がある
OIDCのメリット
認証情報をGitHubシークレットなどで保存しておく必要がない
クラウドプロバイダーの認証、認可ツールをしようすることで、より細かく認証、認可を設定できる
クラウドプロバイダーは単一のジョブに対してのみ有効なアクセストークンを発行するので、当該のアクセストークンはすぐ有効期限になる (リプレイ攻撃などの緩和)
OIDC連携の始め方
https://gyazo.com/8aa1a8c8c4ce239f943063ad8680b098
AWS前提で考えてみる
1. GitHub ActionsのIDプロバイダ(OIDCプロバイダ)の登録、thumprintの登録、割り当てるIAMロールの設定などを行う
この段階でAWSとActionsのワークフローの間で信頼関係が構築される
2. Actionsのワークフローが動くたび、GitHubのOIDC Provider(1.でAWSに登録したやつ)がOIDCトークンを発行する
このOIDCトークンはJWTになってて、クラウドプロバイダーは改ざんされてないことを確認したうで、事前に構築した条件とJWTのクレームの内容が一致するかを確認する
3. 2.で発行したトークンをAWS側へ送る
一般ユーザ向けのOIDCとかだと、ここのフローでユーザがサードパーティ(Twitterとか)の許可画面で許可を押しているところだと思う
と考えると、OIDCプロバイダーは一般ユーザがOIDC認証するときのユーザ許可の操作を肩代わりしている気がする
OIDCトークンにはどのリポジトリのworkflowが動いたかとか、どのGitHubユーザが動かしたかとかの情報含まれる
"プロバイダー"という名前で混乱していた気がするけど、アクセストークンを発行したり許可をするのはAWSで、GitHub Acitons+GitHub OIDCプロバイダーは許可を求める側なはず
4. クラウドプロバイダーは3.で受け取ったトークンのクレーム検証に成功すると、有効期間の短いアクセストークンを発行する
先のOIDC連携の始め方を考慮して考えると、どうも2~3のときに例のthumbprintが何かしらの認証などに使われていて、かつ事前に1.でAWS側に登録されているものが使われているっぽい
ここも混乱してたけど、thumbprintはGitHub OIDC Providerのものである
ここまでを前提にして先日の問題を回避するためにGitHubが公開したブログを読んでみる
そもそも当該のthumbprintは何なのかというと a single intermediary thumbprint from the Certificate Authority (CA) of the Actions SSL certificate とのことで、SSLの中間証明書のthumbprintっぽい
どうやら、クラウドプロバイダーとGitHubのOIDCプロバイダー間のSSL/TLS通信時の検証に使用されるthumbprintのことっぽいな
IAM requires the thumbprint for the top intermediate certificate authority (CA) that signed the certificate used by the external identity provider (IdP). The thumbprint is a signature for the CA's certificate that was used to issue the certificate for the OIDC-compatible IdP.
中間認証局の発行した証明書のhashのことなはず
マイクロソフト系のプロダクトだとfingerprintのことthumbprintと呼ぶのね (いまやGitHubもマイクロソフト系だもんね)
公開鍵の正当性確認のために、公開鍵のhashを確認するケースがあって、この公開鍵のhashのことをfingerprintと呼ぶと
今回のケースだと証明書に対してのhashっぽい気がするけど
まとめ
一般ユーザ向けのOIDCで置き換えて考えると、それぞれの登場自分物は以下とだいたい同じような役割をおってそう
GitHub OIDCプロバイダー: ユーザ
XXのリソースに対してアクセスしたいよ!という認可リクエストをAuthentication Serverへ投げる
AWS: Authentication Server
ユーザからの認可リクエストを受けて、アクセストークンなどを返す
GitHub OIDCプロバイダと、一般ユーザ向けのOIDCのユーザと違うこととして、OIDCプロバイダはユーザが動かしたGitHub Actionsが必要な認可リクエストを肩代わりしてくれる
GitHub OIDCプロバイダとAWSは、事前にAWS側にOIDCプロバイダの情報が登録されていることで信頼関係が構築されている
GitHub OIDCプロバイダのthumbprintもここでAWSに登録されてる
GitHub OIDCプロバイダのSSL認証局の中間証明書が複数に増えた?ことによって、証明書の署名であるthumbprint(増えた証明書の文)をAWS側に事前登録してやらないといけなくなった。