CI-001C — Configure protected short-lived Firebase deployment identity

[daliu]

Outcome

Give GitHub Actions a protected, short-lived, least-privilege identity for Firebase deployment. Prefer GitHub OpenID Connect plus Google Workload Identity Federation. Do not put a downloaded service-account key in the repository, website build, issue, email, screenshot, or AI conversation.

This is an owner/configuration ticket. It is not ready to claim until the owner confirms the target Firebase/GCP project, the staging project, two approved release reviewers, and the private place where IAM evidence will be kept.

Officer impact: Two named officers can approve a backend release without handling or copying a long-lived cloud key.

Officer documentation: Update docs/officers/ACCESS_CONTINUITY.md, docs/officers/PUBLISH_AND_CHECK.md, and OPERATIONS_RUNBOOK.md with only the verified no-secret approval/revocation steps.

Deployment evidence: None at creation. No Firebase, website, provider, or production change is authorized by publishing this ticket.

Why this is atomic

This ticket establishes deployment identity and approval only. It does not deploy application code, Functions, Firestore Rules, indexes, or a website. CI-001D will use the approved identity for a controlled backend-first release.

Prerequisites / owner decisions

• CI-001 — Establish trustworthy quality gates and protected deployment #105 remains the parent delivery tracker.
• BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition #113 confirms the approved target/staging Firebase projects and current cloud estate privately.
• Dave/board names two release reviewers and two account-recovery owners.
• The owner chooses protected GitHub environments for staging and production.
• A cloud/IAM specialist approves the minimum roles after inspecting the exact deploy surfaces. Do not guess broad roles from an issue template.

Required design

1. Use a dedicated deploy principal; never a personal account or frontend identity.
2. Trust only this repository and the approved workflow/environment/ref conditions.
3. Issue short-lived credentials only after protected-environment approval.
4. Separate staging and production authorization when the provider permits it.
5. Grant only permissions required for the reviewed Firestore Rules and targeted Functions deployment. Do not grant project Owner/Editor as a shortcut.
6. Keep runtime service identities separate from the deploy identity.
7. Make missing/mismatched authority fail before any deployment attempt and leave the website unpublished.
8. Redact project numbers, pool/provider IDs, service-account addresses, tokens, policy dumps, and private console links from public evidence.
9. Document revocation, reviewer removal, repository transfer, and compromised-workflow response.

Acceptance criteria

• Private inventory names the staging/target projects, deploy surfaces, runtime identities, deploy identity, and approved owners.
• GitHub environment approval is required and tested with a made-up no-op or read-only staging check.
• OIDC/WIF trust is restricted to the exact repository and approved environment/ref.
• No long-lived cloud credential is stored in GitHub, Netlify, source, build output, logs, or officer instructions.
• Missing authority, wrong repository/ref/environment, and unapproved production attempts fail closed.
• Credential/token output is masked and no provider identifiers are copied into public comments.
• A second authorized owner can revoke access using the private continuity record.
• IAM review records why each permission is necessary and confirms no project Owner/Editor shortcut.
• Source/docs changes, provider configuration, staging proof, and production authorization are reported as separate states.
• CI-001 — Establish trustworthy quality gates and protected deployment #105 links this child and CI-001D remains blocked until this issue closes.

Stop conditions

Stop if a step requests a JSON key, token, password, recovery code, project policy dump, private link, or broad Owner/Editor role in a public place. Stop if the exact target project or named approvers are unknown. Escalate to the platform/security owner and cloud IAM specialist.

Claim protocol

Creation is not a claim. After owner prerequisites are recorded privately, assign one agent, post CLAIMED by <canonical agent> at <UTC>; branch <branch>, and change the label only when the ticket is actually dependency-clear. Provider-console work requires the named human owner present; an agent must not invent or copy secrets.