Context
Firebase CLI currently calls the legacy Service Usage v1beta1 RPC during Gen 2 Functions deployment:
POST https://serviceusage.googleapis.com/v1beta1/projects/{projectNumber}/services/{service}:generateServiceIdentity
for at least pubsub.googleapis.com and eventarc.googleapis.com.
This behavior is present in firebase-tools@13.35.1 and remains present in current released firebase-tools@15.28.2 / current upstream source. The call is awaited during Functions preparation, so a failure is fatal for the deploy preparation path.
Documentation gap
Google's current Service Usage reference documents the HTTP method and OAuth scopes but does not state the IAM permission(s), containing role(s), or authorization resource required to invoke the RPC. The Service Usage access-control method/permission table also does not establish that mapping.
Current Google IAM documentation separately documents Workload Identity GenerateServiceAgents with workloadidentity.serviceAgents.create / workloadidentity.operations.get, but those permissions are explicitly associated with the newer Workload Identity API, not with the legacy Service Usage RPC still used by Firebase CLI.
Clarification requested
- What exact IAM permission(s) are necessary and sufficient to call Service Usage v1beta1
services.generateServiceIdentity?
- On what resource are those permissions evaluated?
- What are the supported semantics when the Google-managed service identity already exists?
- Is there a supported migration/authorization relationship between this legacy RPC and Workload Identity
GenerateServiceAgents?
- Is Firebase CLI expected to migrate away from the legacy RPC, or should least-privilege deploy identities authorize it directly?
Why this matters
Without an authoritative mapping, a least-privilege CI/CD role cannot safely infer whether serviceusage.services.enable, serviceusage.services.use, the newer Workload Identity permission, or some other authority is required. The deployment boundary must therefore remain fail closed.
Context
Firebase CLI currently calls the legacy Service Usage v1beta1 RPC during Gen 2 Functions deployment:
POST https://serviceusage.googleapis.com/v1beta1/projects/{projectNumber}/services/{service}:generateServiceIdentityfor at least
pubsub.googleapis.comandeventarc.googleapis.com.This behavior is present in
firebase-tools@13.35.1and remains present in current releasedfirebase-tools@15.28.2/ current upstream source. The call is awaited during Functions preparation, so a failure is fatal for the deploy preparation path.Documentation gap
Google's current Service Usage reference documents the HTTP method and OAuth scopes but does not state the IAM permission(s), containing role(s), or authorization resource required to invoke the RPC. The Service Usage access-control method/permission table also does not establish that mapping.
Current Google IAM documentation separately documents Workload Identity
GenerateServiceAgentswithworkloadidentity.serviceAgents.create/workloadidentity.operations.get, but those permissions are explicitly associated with the newer Workload Identity API, not with the legacy Service Usage RPC still used by Firebase CLI.Clarification requested
services.generateServiceIdentity?GenerateServiceAgents?Why this matters
Without an authoritative mapping, a least-privilege CI/CD role cannot safely infer whether
serviceusage.services.enable,serviceusage.services.use, the newer Workload Identity permission, or some other authority is required. The deployment boundary must therefore remain fail closed.