Firebase CLIつまりfirebase-toolsが警告を出してたのね。--tokenは危ないからそろそろ止めよう？って。

Authenticating with `--token` is deprecated and will be removed in a future major version of `firebase-tools`. Instead, use a service account key with `GOOGLE_APPLICATION_CREDENTIALS`: https://cloud.google.com/docs/authentication/getting-started

この--tokenで使われるトークンはfirebase login:ciで生成されるもので、Firebase CLIでできることは全部できるはず、たぶん。CIのシークレットなんかに置いて使うとはいえ、権限が強くて持ち運べるものはやっぱり危ない。

環境変数GOOGLE_APPLICATION_CREDENTIALSの場合、そこで使える値には何種類かあって、上記の警告ではservice account keyが推奨されている。これだと実際に使う機能の権限だけをサービスアカウントに付与する運用ができて、危険度が下がる。機能（プロダクト）毎にread/writeやらread-onlyやらadminやら、ずらーっと権限（role）が並んでいるのを眺めると（Firebase product-level predefined roles）、これが丸っと与えられているトークン使うのは怖いね、という気持ちになってくる。（ただし、おそらくここにはFirebase CLIおよび専用のトークンからは利用できない機能も含まれてる。）

でも、service account keyは秘密鍵を含んでいて、なんか嫌だ。そんなあなたにWorkload Identity Federationというのがありまして、実行環境がOIDCのプロバイダ（IdP）も兼ねていると、実行時にID tokenを発行して身元を示せるから、Goole Cloud側は「ああ、◯◯さんところの△△さんね」と身元に応じた鍵をその場で探して渡すことができる。しかも、「このレポジトリのstagingブランチからdeveloper権限で依頼が来たら」みたいな柔軟な条件でIAM roleを設定することができる。OIDCが無ければ「そこまでやらなくても……」とプラットフォーム側も利用者側も考えそうなやつが実現されていて、なんか感動する。（なんでだろうね。経験に裏打ちされた真っ当でオープンな仕様が、真っ当な実装の複雑さを軽減してるから？）

GOOGLE_APPLICATION_CREDENTIALSの話に戻ると、「◯◯というIdPのほうから来ました!!詳しいことはID tokenに書いてます」という紹介状もこの環境変数に入れることができるのだ。PKIおよびOIDCに守られた確かな紹介状と、事前に登録しておいたIdP等々の情報を元に、Google Cloud側は然るべき権限を持ったトークンを返すことができる。CIの設定を持つレポジトリにはこの紹介状の発行依頼を置くだけだから、これが漏れても他の実行環境で紹介状は発行されない（からGoogleに認証もされない）し、詳しい自己紹介（組織、レポジトリ、ブランチ、CI実行したアカウントの権限など）は実行時に実行環境=IdPが書いてくれる。美しい。

さて、今このサイトはこの仕組みでデプロイされています。次回はそこに至るまでの数々の罠について……。