『GitHub Appの秘密鍵をGitHub Secretsから追い出す - 10X Product Blog』で個人的に作って公開しているyagihash/ghatを紹介してもらってから地味にStarをもらっていて嬉しい。個人的に、といっても個人でも使いたいものを仕事で使う用事があったので作った、というのが実際のところで、実際に良い感じに使ってもらえているので良かった。(導入も自分でやったんだけどねw)
今日はyagihash/ghatのactionとしての使い方ではなく、個人的に気に入っているローカルでの使い方を紹介したい。先日ポッドキャストでもちらっと言及したので、せっかくだし記事にしておくか、と思い立った次第。
Actionsの中で使うGitHub App Token絡みのデバッグむずい問題
GitHub Appのパーミッションはけっこう細かくて、yagihash/ghatのaction.ymlを見てもらうとわかるんだけど、54個のパーミッションがある。GitHub Appの権限を細かく制御しながらややこしいことをしようとすると、パーミッションが足りてるのか足りてないのかよくわからん問題のトラブルシュートをするハメになるのがあるあるで、最近 babarot/gh-infraでGitHubのリポジトリ管理をしようと思ってまさにそういうややこしい挙動に沼っていたりする。細かい経緯は省略するけど、こないだは共通のGitHub Actionsのworkflowファイルを配布しようとしてなぜか通らず、Claude Codeは全然役に立たなくて結局自分でworkflows:writeがないと.github/workflows配下に書き込めないじゃん、というのに気づいてパーミッションを追加する、みたいな場面もあった。(割とちょろい系のトラブルなので例えとしてはあんま通じない気がするけども…)
トラブルシューティングのためにActionsの中で使っているのと同一のGitHub App Tokenが欲しい…というのもまたあるあるで、そんなときにyagihash/ghatを地味に便利に使っているよ、というのが今日の話。
実はgo installもできるyagihash/ghat
『Google Cloud KMSの鍵を使ってGitHub App Tokenをつくるactionをつくった』でもさらっと言及してるんだけど、手癖で書けて早かったのでGo+Docker actionで実装していて、そのせいでubuntu-slimとかでは使えないという残念な制約も生じてしまっているんだけど、一方で副産物としてビルドした実行ファイルは別にActionsの環境じゃなくても簡単に実行できるという利点も生まれた。別にNodeじゃできないというものでもないんだけど、実行ファイルをそのまま持ってくればおしまい、というのはそれなりに良いところなのかなーと思っている。
鍵の実体がKMSの中にあるので、gcloudの認証を済ませておくのと、自分自身に対象の鍵のroles/cloudkms.Signerのロールを付与しておけば、こんな感じで動かせる。(READMEにも記載している。)
go install github.com/yagihash/ghat/v2/cmd/ghat@latest
INPUT_KMS_PROJECT_ID=YOUR_GOOGLE_CLOUD_PROJECT_ID \
INPUT_KMS_KEYRING_ID=YOUR_KMS_KEYRING_ID \
INPUT_KMS_KEY_ID=YOUR_KMS_KEY_ID \
INPUT_KMS_LOCATION=YOUR_KMS_REGION \
INPUT_OWNER=YOUR_GITHUB_USER_OR_ORG_NAME \
INPUT_APP_ID=YOUR_GITHUB_APP_ID \
ghat
# with env vars
GH_TOKEN=$(ghat) gh auth status
もちろんINPUT_PERMISSION_CONTENTS=readとかREPOSITORIES=foo/bar,foo/buzみたいな環境変数を渡してあげればパーミッションやリポジトリを限定することもできるので、Actionsでのyagihash/ghatの呼び出し方と合わせてあげれば同一のGitHub App Tokenがローカルでも手に入る。
個人的にはこの使い方をしたいリポジトリに.envrcを置いてdirenvで勝手に環境変数が設定されるようにすることがある。
注意点
yagihash/ghatをGitHub Actionsで使う場合は実行後にcleanup処理が走って、作ったGitHub App Tokenをinvalidateしてくれるけど、ローカルで動かす場合はそこまではやってくれないので作ったtokenの取り扱いには注意が必要。
あと、例えば仕事でこの使い方を常時許容できるかというとまったくそんなわけはないのでそこは注意して欲しい。個人開発で、Google Cloudの権限管理が大雑把だからできていることであって、仕事でこんな重要な鍵の署名処理へのアクセスを個人に常時付けておいていいわけがないので、せいぜい手強いバグに立ち向かうときに一時的に…みたいな使い方に留めて欲しい。