背景
- Firebaseを利用してサービスをデプロイしていた
- Github Actionsを利用して自動的に
firebase deployコマンドを叩いてデプロイさせたかった - どうやらそれには、GCPでサービスアカウントを生成する必要があるようだ
- サービスアカウントって何？という備忘録
サービスアカウントとは
サービス アカウントは、ユーザーではなく、アプリケーションや Compute Engine インスタンスなどのコンピューティング ワークロードで通常使用される特別なアカウントです
Google Cloud においてアプリケーションやサービスが自身を識別し、Google Cloud リソースへのアクセスを認証・認可するために使用する特別なアカウント
人間がパスワードを使ってログインするように、サービスアカウントもキー（認証情報）を使ってGoogle Cloudにアクセスする。つまり、プログラムが使うための専用アカウントという位置づけ
GitHub Actionsで必要な理由
認証と認可
GitHub ActionsはGoogle Cloudの外部システムです。
そのため、Google Cloudのリソースにアクセスするには、当然ながら認証が必要になります。
サービスアカウントは、この認証を行うためのIDとして機能します。
Google Cloud側に「特定のワークフローからの操作を受け付ける」ようにする設定が必要です。
権限の管理
サービスアカウントに特定の IAM ロールを付与することで、GitHub Actions から Firebase に対して許可する操作を細かく制御できます。
たとえば、Hosting へのデプロイや Cloud Functions の更新など、必要な最小限の権限のみを与えることで、セキュリティリスクを軽減できます。
具体的な流れ
1. Google Cloudでサービスアカウントを作成する
Firebaseプロジェクトが含まれるGoogle Cloudプロジェクト内で、GitHub Actions用の新しいサービスアカウントを作成する
2. 必要なロールを付与する
作成したサービスアカウントに、Firebaseのデプロイに必要なIAMロール（例: Firebase管理者、Firebase Hosting管理者など）を付与する
3. サービスアカウントキーを取得する
サービスアカウントの認証情報として、JSON形式のキーファイルを生成する。
人間がパスワードでログインするのと同じように、サービスアカウントもこのキーで認証を行う
4. GitHub Actionsにキーを設定する
取得したJSONキーの内容をGitHubのSecrets機能に安全に保存する
これにより、GitHub Actionsワークフローからこのキーを参照して認証を行うことができる
5. GitHub Actionsワークフローで利用する
ワークフローのステップで、保存したサービスアカウントキーを使って認証し、Firebase CLIでデプロイコマンドを実行する
補足: Workload Identity連携
最近では、Workload Identity連携というよりセキュアな方法も利用できる。
これはサービスアカウントキーを直接GitHubに保存する代わりに、GitHub ActionsのOIDC（OpenID Connect）トークンを使ってGoogle Cloudのサービスアカウントに一時的にアクセス権を付与する仕組み。
キーの漏洩リスクがなくなるため、セキュリティ面ではこちらが推奨されている。
firebase deploy と firebase deploy --only hosting の違い
ここで少し脱線するが、firebase deployコマンドについても整理しておく。
firebase deploy（オプションなし）
Firebaseのリソースをまとめてデプロイする。対象は以下の通り。
| リソース | 役割 |
|---|---|
| Hosting | フロントエンドを公開する場所（HTML, CSS, JS, 画像などの静的ファイル） |
| Cloud Functions | サーバーサイドの処理 |
| Firestore ルール | データベースのセキュリティルール |
| Storage ルール | ファイルストレージのセキュリティルール |
firebase deploy --only hosting
Hostingだけをデプロイする。
フロントエンドの変更だけを反映したい場合は、こちらを使うことで不要なデプロイを避けられる。
感想
- Firebase結構細かく設定できるんだと思いました。コマンド1回でデプロイできるのはかなりユーザー体験良さげ
参考