開発事業部の dascarlet です。今回は Cloud Firestore セキュリティ ルールを GitHub で管理するように変更し、GitHub Actionsからデプロイできるようにしたお話をします。
経緯
今までのセキュリティルールの運用では以下のような改善できる点がありました。
1. ルールの更新から属人性を排除したい
特定のエンジニアだけが更新作業にあたるのではなく、必要なときに誰でも更新できるような仕組みにしたかったという背景がありました。今回は GitHub Actions を採用することによって、リポジトリにアクセスできる人であれば誰でも Pull Request 作成&デプロイまで可能になりました。
2. 変更をレビューできるようにしたい
Google の GUI コンソールからの更新だと、誰がいつ何を更新したかがわかりにくくなる。また、レビューも大変、という背景がありました。ルールをコードで管理し、変更に際して Pull Request を使用することで、レビューができるという利点が生まれました
これらの改善点は今回の変更で達成できたのかなと思います。
ディレクトリ構成
今回は、新しいリポジトリを作成し、そこでルールを管理するようにしました。
ディレクトリ構成は以下です。Google Cloud上のプロジェクトは開発環境用と本番環境用、2つ存在しています。
(root) ├── .github │ └── workflows │ ├── dev-deploy-firestore-rules.yaml │ └── prod-deploy-firestore-rules.yaml ├── README.md └── firebase ├── develop │ ├── firebase.json │ └── firestore-dev.rules └── production ├── firebase.json └── firestore-prod.rules
ルールの定義ファイルを2つに分けているのは、開発環境で新しいルールを試したいというニーズにも答えるためです。多少、 dev
や prod
の文字が冗長なように感じられるかもしれませんが、開発環境か本番環境かどちらを今作業しているのかを意識できるように、意図的に命名しているものになります。
json の中身は以下です。 rules
に実際のファイル名を指定することで、デプロイ時にファイルを認識してくれるようになります。
{ "firestore": { "rules": "firestore-dev.rules" } }
ルールのファイルの中身は省略します。ドキュメント等をご覧ください。
デプロイ
GitHub Actions で利用する開発環境用の定義は以下です。
name: Dev Firestore rules on: workflow_dispatch jobs: deploy-dev: name: Deploy Firestore dev rules runs-on: ubuntu-latest defaults: run: working-directory: ./firebase/develop steps: - name: Checkout Repo uses: actions/checkout@v3 - name: Deploy to Firebase dev uses: w9jds/firebase-action@v2 with: args: deploy --only firestore:rules env: GCP_SA_KEY: ${{ secrets.DEPLOY_RULES_SA_DEV }} PROJECT_ID: ${{ your_gcp_project_id }} PROJECT_PATH: ./firebase/develop
本番環境用の定義も、ほとんど同じものを利用しています。
運用
GitHub Actions のワークフローで、 on: workflow_dispatch
を設定しているため、以下の運用にしています。
- 開発環境のルールファイルに変更を加え、Pull Requestを作成する
- 他のメンバーがレビューする
- main ブランチへマージする
- GitHub Actions 上でワークフローを手動実行する
デプロイするのは基本的に main ブランチのファイルですが、必要に応じてデプロイ対象のブランチを指定することも出来ます。