Workload Identity / Service Accounts, Keyless Credentials, Secrets, Rotation, and Local Development

1. Credentials are deployment architecture, not a JSON file

A common tutorial initializes the Admin SDK with a downloaded service-account key and stops there. That is convenient but operationally dangerous: a long-lived private key can be copied, committed, leaked in a support bundle or shipped into a container image. Modern Google Cloud authentication provides safer ways for workloads and developers to obtain short-lived credentials without owning a persistent key file.

Learning outcomes

2. How ADC chooses credentials

Application Default Credentials (ADC) is a standard way for Google-authenticated client libraries to locate credentials. In simplified priority order, ADC can use credentials pointed to by GOOGLE_APPLICATION_CREDENTIALS, a well-known local ADC file created by tooling, or credentials supplied by the runtime metadata service/attached identity. The safe architecture chooses the source deliberately rather than hoping the library finds “something that works.”

3. Mandatory lab: prove the emulator path needs no cloud credential

# Mandatory emulator path: no Google Cloud credentials are needed.export FIRESTORE_EMULATOR_HOST="127.0.0.1:8080"export FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"export GCLOUD_PROJECT="demo-atlasmart-firestore"node backend-path.test.mjs# Optional real-project local development, only in an isolated project:# gcloud auth application-default login# Prefer user ADC or service-account impersonation over downloading a JSON key.# Never do this in browser code or commit the referenced file:# export GOOGLE_APPLICATION_CREDENTIALS="./service-account-key.json"

// Never ship this module to a browser bundle.process.env.FIRESTORE_EMULATOR_HOST = "127.0.0.1:8080";process.env.FIREBASE_AUTH_EMULATOR_HOST = "127.0.0.1:9099";process.env.GCLOUD_PROJECT = "demo-atlasmart-firestore";import { initializeApp } from "firebase-admin/app";import { getAuth } from "firebase-admin/auth";import { getFirestore } from "firebase-admin/firestore";initializeApp({ projectId: "demo-atlasmart-firestore" });export const adminAuth = getAuth();export const adminDb = getFirestore();

With both emulator host variables configured, the Admin SDK talks to local emulators. This is precisely why mandatory labs do not ask learners to create or download service-account keys. The emulator trust model is not production IAM; it is a deterministic local environment for application behavior.

4. Workload Identity Federation: exchange external identity for short-lived Google credentials

Workload Identity Federation (WIF) allows an external workload—such as a CI job, AWS/Azure workload or OIDC-capable platform—to authenticate using its native identity and obtain short-lived Google credentials. The key security improvement is that the external environment does not need a persistent service-account private key.

5. Service accounts are resources; keys are credentials

Do not confuse a service account with a service-account key. A service account is an IAM principal/resource. It can be attached to a Google Cloud runtime or impersonated/federated without a downloadable private key. Keyless operation therefore does not mean “no service account”; it means the workload obtains short-lived credentials through a trusted platform/federation flow.

PROJECT_ID="YOUR_ISOLATED_PROJECT"SA="atlasmart-orders-api@${PROJECT_ID}.iam.gserviceaccount.com"# Create one workload identity for one service responsibility.gcloud iam service-accounts create atlasmart-orders-api   --project="$PROJECT_ID"   --display-name="AtlasMart orders API"# roles/datastore.user permits Firestore entity read/write operations.# It is still broader than per-customer authorization; application code must enforce that.gcloud projects add-iam-policy-binding "$PROJECT_ID"   --member="serviceAccount:${SA}"   --role="roles/datastore.user"# Inspect exactly what the principal has before deployment.gcloud projects get-iam-policy "$PROJECT_ID"   --flatten="bindings[].members"   --filter="bindings.members:serviceAccount:${SA}"   --format="table(bindings.role)"

6. Wrong approach: ship a service-account JSON file with the app

// NEVER put a service-account JSON object in browser/mobile code.// NEVER commit it to Git.// NEVER embed it in a desktop/mobile binary.initializeApp({  credential: cert(JSON.parse(process.env.PUBLIC_SERVICE_ACCOUNT_JSON))});

A browser/mobile application is an untrusted environment. Any embedded secret can be extracted. The correct client identity is Firebase Authentication (plus App Check where appropriate), while privileged credentials remain in trusted runtime infrastructure.

7. Secrets, credentials and rotation are different concerns

Rotation plans should answer: which workloads depend on this credential, how do you deploy the replacement, how do you prove the old credential no longer works, and how do you detect unexpected use during the transition?

8. Enterprise and MongoDB compatibility boundary

Enterprise Native server clients use the same privileged IAM/ADC trust model: Core and Pipeline operations do not make server SDKs subject to client Security Rules. Firestore with MongoDB compatibility has its own connection model and can authenticate through supported Google/OIDC workload identities or database-user credentials such as SCRAM depending on the connection path. Do not reuse a Native-mode mobile/web security diagram for a MongoDB driver.

9. Verification and cleanup

• Search the lab directory for private_key, client_email, GOOGLE_APPLICATION_CREDENTIALS and raw Bearer values; none should be committed.
• Mandatory emulator scripts succeed with no cloud credential.
• Production deployment design names one explicit workload identity per service responsibility.
• Optional cloud test records the exact principal and roles, then removes temporary bindings/resources.
• Document an emergency disable/revocation procedure before first production deployment.

Production judgment and bridge to Lesson 5

The safest credential is often the one you never download. Prefer attached identities in Google Cloud and federation/impersonation elsewhere. Keep human local-development credentials distinct from production workloads. Lesson 5 combines all of Chapter 14 into one end-to-end AtlasMart access architecture with explicit trust, audit, failure and recovery boundaries.

Knowledge check

1. What is ADC?
2. Why is an attached service account safer than a downloaded key?
3. What problem does Workload Identity Federation solve?
4. Should FIREBASE_AUTH_EMULATOR_HOST ever be set in production?
5. Does keyless mean there is no workload identity?

Summary

AtlasMart now treats credentials as an architecture choice. Emulator work is credential-free, developers use bounded ADC/impersonation, production workloads use attached/federated identities where possible, and service-account keys are a last-resort secret with explicit lifecycle controls.

Authoritative references

• Secure data in Cloud Firestore
• Firestore IAM
• Security Rules conditions and server-library bypass
• Add the Firebase Admin SDK to your server
• Verify Firebase ID tokens
• Custom claims and access control
• Manage user sessions and token revocation
• Connect to the Authentication emulator
• Connect to the Firestore emulator
• How Application Default Credentials works
• Best practices for service accounts
• Workload Identity Federation
• Firestore IAM roles and permissions
• Authenticate and connect with Firestore MongoDB compatibility
• Enterprise Native server client libraries
• Firebase Admin Node.js SDK release notes
• Firebase CLI release notes