Firestore Security: IAM Policies and Network Security

Understanding Firestore Security: IAM Policies and Network Security

Firestore security extends far beyond the well-known Firestore Security Rules. While security rules govern per-document access for client-side SDKs, the administrative and infrastructure layers rely on two critical mechanisms: IAM policies and network security controls. IAM policies define who can manage the Firestore database, perform bulk operations, export data, or alter index configurations. Network security determines from which networks, IP addresses, or Google Cloud perimeters the Firestore API can even be reached. Together they form a defense-in-depth strategy that protects your Firestore data from unauthorized administrative access, accidental exposure, and network-based exfiltration.

Why IAM Policies and Network Security Matter

Firestore stores sensitive application data—user profiles, financial records, chat histories, and more. A misconfigured IAM role could grant a contractor or a compromised service account the ability to export your entire dataset. An overly permissive network configuration might allow an attacker outside your organization to reach the Firestore API directly, bypassing application-level checks. IAM and network security act as the first line of defense:

• IAM policies control management plane access: creating/deleting databases, updating indexes, running imports/exports, and reading/writing data via server-side SDKs using service accounts.
• Network security controls data plane and management plane access at the perimeter: only requests originating from approved IP ranges, VPC networks, or authorized Google Cloud services are allowed to reach the Firestore API endpoints.

Without these layers, even perfectly written Firestore security rules could be undermined by a stolen service account key or an insider threat.

How IAM Policies Work with Firestore

Firestore IAM Roles and Permissions

Firestore uses the datastore API under the hood, so its IAM roles are shared with Cloud Datastore. The most common predefined roles are:

• roles/datastore.user – Full read/write access to Firestore data, but no administrative operations like index creation or database exports.
• roles/datastore.viewer – Read-only access to Firestore documents and indexes.
• roles/datastore.owner – Full control over data and administrative operations (create indexes, export/import, manage database).
• roles/datastore.admin – Complete management of the Firestore database, including deleting databases and all configuration.

In addition, Firebase-specific roles like roles/firebase.admin grant broader project-level privileges that include Firestore administrative capabilities. For production applications, always prefer the most granular role possible.

Assigning IAM Policies via Google Cloud Console

Navigate to the IAM & Admin section, select your project, and click "Grant Access". Enter the member (user, group, or service account) and choose one of the datastore roles above. This assigns permissions at the project level, affecting all Firestore databases within that project. For finer control, you can apply roles at the database instance level using the Firestore UI or CLI.

Using gcloud CLI to Manage IAM Policies

The command-line interface offers precise, repeatable policy bindings. The following example grants the datastore.user role to a developer's account:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member='user:dev-user@example.com' \
  --role='roles/datastore.user'

To grant a role to a service account (for server-side SDKs running on Cloud Run, GKE, or Compute Engine), use:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member='serviceAccount:my-app-sa@your-project.iam.gserviceaccount.com' \
  --role='roles/datastore.user'

Always verify the binding with gcloud projects get-iam-policy YOUR_PROJECT_ID and store your policy definitions in version-controlled YAML files for auditability.

IAM Conditions for Attribute-Based Access Control

IAM Conditions allow you to restrict permissions based on attributes like the requesting IP address, the time of day, or the originating VPC network. This is extremely powerful for enforcing network-based restrictions directly within the IAM layer. For example, to grant the datastore.user role only when the request comes from a specific IP range (such as your corporate VPN):

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member='serviceAccount:app-sa@your-project.iam.gserviceaccount.com' \
  --role='roles/datastore.user' \
  --condition='title=allowed_ip_range,expression=requestIpInRange(["203.0.113.0/24"])'

The expression uses the IAM Condition Language. You can combine conditions:

expression=requestIpInRange(["10.0.0.0/8"]) || request.time.getFullYear() == 2025

IAM Conditions are evaluated at runtime when the API call is made. If the condition evaluates to false, the role binding is ignored, effectively denying the request. This provides a robust way to enforce network security directly in IAM without relying solely on network controls.

IAM Policy Inheritance and Service Accounts

IAM policies at the project level are inherited by all Firestore instances in that project. For server-side SDKs (Node.js, Python, Java, Go), you authenticate using a service account. That service account must have the appropriate datastore role. Avoid downloading service account keys whenever possible; use workload identity on Cloud Run, GKE, or Compute Engine to bind a Kubernetes service account or instance to the Google service account. This reduces the risk of key exfiltration.

How Network Security Works for Firestore

Firestore Security Rules vs Network Security

Security rules evaluate requests coming from client-side SDKs (web, mobile) based on user authentication and document content. Network security operates at a lower level—before the request ever reaches the security rules engine. If the request originates from an unauthorized network, it is blocked outright. This protects against:

• Direct API calls using leaked service account credentials from outside your organization.
• Data exfiltration attempts from compromised cloud resources in other projects.
• Accidental exposure of Firestore API endpoints to the public internet.

VPC Service Controls (VPC SC)

VPC Service Controls create a security perimeter around Google Cloud services, including Firestore. Resources inside the perimeter can only access services within that perimeter unless explicit egress rules allow otherwise. This prevents data from moving out of your trusted network even if an attacker gains access to a service account. To set up a VPC Service Perimeter that restricts Firestore:

gcloud access-context-manager perimeters create my-perimeter \
  --title="Firestore Data Perimeter" \
  --policy=YOUR_ACCESS_POLICY_ID \
  --resources=projects/YOUR_PROJECT_ID \
  --restricted-services=datastore.googleapis.com \
  --type=PERMANENT

Once the perimeter is active, only requests originating from resources within the same perimeter (like Cloud Functions, Cloud Run, or GCE instances inside allowed VPC networks) can call datastore.googleapis.com. External requests, even with valid IAM roles, will be denied. You can also use VPC accessible services to selectively allow certain services from outside, and configure ingress/egress rules for more granular control.

Firestore and Private Google Access / Private Service Connect

If your workloads run on-premises or in hybrid environments, you can connect to Firestore over private IP addresses using Private Google Access or Private Service Connect. This ensures traffic never traverses the public internet. For example, you can configure an on-premises VPN tunnel to a VPC and enable Private Google Access on the subnet, allowing your internal services to call datastore.googleapis.com through RFC1918 addresses. No public DNS resolution or exposure is required.

Using Cloud Firewall Rules with Firestore

Although Firestore itself is a serverless API and not directly protected by VPC firewall rules, the clients accessing Firestore (GCE VMs, GKE nodes) can be restricted by egress firewall rules. For example, you might create a firewall rule that allows egress traffic only to datastore.googleapis.com (port 443) from your production subnet. This adds an extra layer to prevent a compromised instance from uploading data to unauthorized destinations. However, the primary network guard for Firestore remains VPC Service Controls and IAM Conditions.

Best Practices for Firestore IAM and Network Security

• Least privilege IAM roles – Always assign datastore.user for data access, reserving datastore.admin only for administrative automation pipelines.
• Use IAM Conditions for IP restrictions – Bind critical roles like datastore.owner with IP conditions to limit where administrative actions can originate.
• Enforce VPC Service Controls – Create a dedicated perimeter for your production projects that includes Firestore. Run in dry-run mode first to identify violations before enforcing.
• Audit IAM policies regularly – Use gcloud to export and review policies. Set up Cloud Asset Inventory alerts for role changes.
• Enable Firestore audit logs – Admin Activity audit logs and Data Access logs track who accessed or modified data. Export them to Cloud Logging and set alerts for anomalous exports or deletions.
• Use workload identity, not service account keys – Bind service accounts to your compute resources without ever downloading keys.
• Combine security rules with network controls – Security rules protect against unauthorized client-side access; network security protects the API endpoint itself. Both are necessary.
• Restrict database creation permissions – Use IAM to control who can create new Firestore database instances; unmanaged databases can lead to data sprawl and overlooked security configurations.

Conclusion

Firestore security is a multi-layered responsibility. IAM policies define who can do what at the administrative and data level, while network security controls determine where those actions can originate. By combining least-privilege IAM roles, IAM Conditions, VPC Service Controls, and rigorous auditing, you build a resilient defense that protects your Firestore data from both internal misconfigurations and external threats. Always treat Firestore security holistically—a perfectly tuned set of security rules means little if an attacker can bypass them entirely by calling the API from an unrestricted network with a stolen service account. Integrate these practices into your deployment pipeline and continuously monitor for drift, and you’ll establish a robust, cloud-native security posture for your Firestore-powered applications.