Merge ci/firestore-sa-auth: service-account auth for Firestore rules deploy (#51)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

.gitea/workflows/deploy.yml

@@ -307,28 +307,30 @@ jobs:
 
       - name: Deploy firestore rules and indexes
         env:
-          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
+          FIREBASE_SA_KEY: ${{ secrets.FIREBASE_SA_KEY }}
         run: |
           set -e
           # server-26#51: this used to run over SSH on the deploy VM, gated
           # on the VM having firebase-tools installed. It never did, so it
           # silently warned-and-skipped on every single deploy for weeks.
-          # Running it here instead means the only prerequisite is a secret
+          # Auth is a dedicated service account (drb-ci-firestore-deploy,
-          # -- FIREBASE_TOKEN, from `firebase login:ci` -- rather than
+          # roles: Firebase Rules Admin, Cloud Datastore Index Admin,
-          # something installed by hand on a machine this pipeline doesn't
+          # Service Usage Consumer), its JSON key stored as the
-          # otherwise touch. A missing token now fails this job LOUDLY
+          # FIREBASE_SA_KEY secret. Not `firebase login:ci`: those tokens are
-          # (picked up by notify-failure) instead of a buried warning line
+          # deprecated and carry the full permissions of whoever minted them.
-          # nobody reads in the app deploy's logs.
+          # A missing key fails this job LOUDLY (picked up by notify-failure).
-          if [ -z "$FIREBASE_TOKEN" ]; then
+          if [ -z "$FIREBASE_SA_KEY" ]; then
-            echo "FIREBASE_TOKEN secret is not set -- cannot deploy Firestore rules/indexes." >&2
+            echo "FIREBASE_SA_KEY secret is not set -- cannot deploy Firestore rules/indexes." >&2
-            echo "Generate one with 'firebase login:ci' and add it as a Gitea Actions secret." >&2
+            echo "Add the drb-ci-firestore-deploy service account's JSON key as a Gitea Actions secret." >&2
             exit 1
           fi
+          export GOOGLE_APPLICATION_CREDENTIALS="$RUNNER_TEMP/firebase-sa.json"
+          trap 'rm -f "$GOOGLE_APPLICATION_CREDENTIALS"' EXIT
+          ( umask 077 && printf '%s' "$FIREBASE_SA_KEY" > "$GOOGLE_APPLICATION_CREDENTIALS" )
           npm install -g firebase-tools
           cd infra/firestore
           firebase deploy --only firestore:rules,firestore:indexes \
-            --project ${{ secrets.FIREBASE_PROJECT_ID }} \
+            --project ${{ secrets.FIREBASE_PROJECT_ID }} --non-interactive
-            --token "$FIREBASE_TOKEN" --non-interactive
 
   notify-failure:
     name: Report a failed deploy
@@ -371,7 +373,7 @@ jobs:
           # failed before any deploy was attempted" text even when the app
           # deployed fine and only the Firestore rules/indexes push failed.
           if deploy_result != "failure" and rules_result == "failure":
-              detail = "App deploy succeeded; Firestore rules/indexes deploy FAILED (server-26#51). Rules may be stale — check FIREBASE_TOKEN and the job log."
+              detail = "App deploy succeeded; Firestore rules/indexes deploy FAILED (server-26#51). Rules may be stale — check the FIREBASE_SA_KEY secret and the job log."
 
           # server-26#65: the old text here unconditionally claimed
           # "production is still running the previous build" -- true only

infra/firestore/firestore.rules

@@ -8,13 +8,11 @@
 // hand-set in the Firebase console: unversioned, unreviewed, unknown. See
 // SAAS_PLAN.md B1.
 //
-// DEPLOY IS A MANUAL, OUT-OF-BAND STEP — nothing in CI or this codebase
+// DEPLOYED BY CI on every push to main (.gitea/workflows/deploy.yml, job
-// pushes these rules to Firebase:
+// deploy-firestore-rules, service-account auth via the FIREBASE_SA_KEY
-//   firebase deploy --only firestore:rules --project <project-id>
+// secret — server-26#51). That job is separate from the app deploy, so a
-// (from this directory, or point --config at infra/firestore/firebase.json
+// green app deploy does NOT mean these rules are live: check that job too.
-// from the repo root). Do this before or immediately after the code that
+// Editing rules in the Firebase console is overwritten by the next push.
-// starts stamping org_id ships — until these rules are live, the
-// console-configured rules are still what's actually enforced.
 //
 // MODEL: c2-core (firebase-admin SDK, server-side) bypasses these rules
 // entirely and is the sole writer for every collection below — that was