VPC / Private Google Access and Service Perimeter Concepts Where Applicable, Egress Paths, and Trusted Backends

1. AtlasMart problem: “private network” is not a database authorization model

AtlasMart moves privileged settlement and fraud services onto private-IP Cloud Run/VM infrastructure. A team member proposes: “Once Firestore traffic comes from our VPC, we can loosen IAM and Rules.” That collapses network origin, identity, and authorization into one trust decision. A compromised workload inside a trusted network would then have an oversized blast radius.

2. Four gates, four different questions

3. Native mode: VPC Service Controls protects the Firestore service

Firestore Native integrates with VPC Service Controls. The Firestore, Datastore, and Firestore Key Visualizer APIs are bundled for perimeter restriction. For private-IP workloads, Private Google Access lets hosts reach Google APIs without an external IP. For stronger exfiltration mitigation, restricted.googleapis.com can be used for services supported by VPC Service Controls. Routing still uses the Google API path; “private” here does not mean you created a dedicated Firestore NIC inside your VPC.

workload: atlasmart-settlementsource: vpc/atlasmart-prod/private-subnetexternal_ip: falseprivate_google_access: trueapi_domain_policy: restricted.googleapis.comservice_perimeter: atlasmart-sensitiveidentity: settlement-saiam: least-privilege-firestoreapplication_authz: tenant + settlement-rolepublic_client_path: separate; Security Rules + App Check

4. Regional endpoints are about processing locality, not “private IP Firestore”

Native server client libraries can target regional or multi-regional Firestore endpoints to enforce data transmission, storage, and processing locality for the specified location. Mobile/web SDKs do not support this endpoint selection. Regional endpoints and Private Google Access therefore solve different requirements: one constrains service endpoint locality; the other gives private-IP workloads a private path to Google APIs. A design can require one, both, or neither.

Do not invent a compliance guarantee from the word “regional.” The policy must name the exact database location, endpoint, callers, and evidence required by your organization.

5. MongoDB compatibility has a distinct private access path

Firestore with MongoDB compatibility uses firestore.goog, not the standard firestore.googleapis.com endpoint. Google documents Private Google Access specifically for this mode. restricted.firestore.goog uses addresses only routable from within Google Cloud and is designed for VPC Service Controls scenarios. The protocol remains MongoDB-compatible over port 443.

6. Safe perimeter rollout: dry-run before deny

Service-perimeter mistakes can create outages. A production rollout should inventory callers, destinations, cross-project access, CI/CD, backup/export buckets, observability tools, and admin workflows. Use dry-run where available, inspect violations, define explicit ingress/egress exceptions, and only then enforce.

{  "restrictedService": "firestore.googleapis.com",  "allowedSources": ["settlement-sa@prod", "fraud-sa@prod"],  "allowedProjects": ["atlasmart-prod"],  "egressExceptions": ["approved-audit-project"],  "denyExamples": [    "developer-laptop-to-prod",    "unknown-service-account",    "export-to-unapproved-project"  ]}

The local test runner should reject every denyExamples entry. This tests your policy model; it does not prove Google Cloud perimeter evaluation.

7. Failure injection: over-trusting the VPC

Deliberately give a simulated in-VPC service an admin=true flag but a tenant mismatch. The expected result is still deny at application authorization. Then remove the application check and observe the test fail. This is the concrete proof that network trust is an input to authorization architecture, not authorization itself.

function authorizeSettlement({ principal, tenant, orderTenant }) {  if (!principal.vpcTrusted) throw new Error("NETWORK_CONTEXT_DENIED");  if (!principal.iam.includes("firestore.write")) throw new Error("IAM_DENIED");  if (tenant !== orderTenant) throw new Error("TENANT_DENIED");  if (!principal.roles.includes("settlement")) throw new Error("APP_AUTHZ_DENIED");  return true;}const attackerInsideVPC = {  vpcTrusted: true, iam: ["firestore.write"], roles: ["settlement"]};try { authorizeSettlement({principal: attackerInsideVPC, tenant:"tenant-a", orderTenant:"tenant-b"}); }catch (e) { console.log(e.message); } // TENANT_DENIED

Production judgment

Use VPC Service Controls when exfiltration threat and governance justify the operational complexity. Use Private Google Access/restricted paths when private-IP workloads should not depend on public internet routing. Keep browser/mobile access patterns separate because Firebase client traffic, Auth, App Check, Rules, and service-perimeter behavior have different constraints. Model every exception as a controlled data path with owner, reason, expiry/review, and audit evidence.

Knowledge check

1. Does Private Google Access grant Firestore IAM permission?
2. What threat does VPC Service Controls primarily mitigate?
3. Are regional endpoints the same thing as Private Google Access?
4. Does MongoDB compatibility use the same endpoint naming as Native?
5. Why use dry-run before perimeter enforcement?

Authoritative references

• Firebase: Server-side encryption — Google-managed encryption, CMEK, client-side encryption distinction, and TLS in transit.
• Google Cloud: Firestore Native CMEK — availability behavior, rotation, backup/restore interaction, and limitations.
• Google Cloud: Firestore Native VPC Service Controls — Firestore service perimeter behavior.
• Google Cloud: Firestore locations — regional/multi-region topology and immutable database location.
• Google Cloud: Firestore regional endpoints — server-library data-locality endpoint behavior.
• Google Cloud: Private Google Access for Firestore with MongoDB compatibility — firestore.goog and restricted.firestore.goog private routing.