Encryption at Rest / In Transit, Google-Managed Keys, CMEK Concepts, Key Availability, Rotation, and Failure Impact

1. AtlasMart problem: encryption can become an availability dependency

AtlasMart stores customer contact details, order history, support notes, and seller settlement metadata. The team correctly knows that Firestore encrypts stored data by default, but a compliance review now requires explicit key ownership and a tested response if a customer-managed key is disabled. The dangerous shortcut is to say “enable CMEK” and stop there. CMEK changes who controls an encryption dependency; it does not make authorization, logging, backup, deletion, or network design disappear.

2. Encryption layers: the same word hides different control planes

3. CMEK creation contract and trust path

CMEK must be selected when the database is created; an existing Google-default-encrypted database cannot simply be switched in place. The Cloud KMS key must be in the same location as the Firestore database. The Firestore service agent needs roles/cloudkms.cryptoKeyEncrypterDecrypter on the key. The KMS project may be different from the Firestore project, but cross-project ownership must be intentional and audited.

# OPTIONAL: real isolated Google Cloud project only# Placeholders intentionally prevent accidental execution.gcloud firestore databases create \  --database=atlasmart-governed \  --location=FIRESTORE_LOCATION \  --kms-key-name=projects/KMS_PROJECT/locations/KMS_LOCATION/keyRings/RING/cryptoKeys/KEY# Verify metadata after creationgcloud firestore databases describe --database=atlasmart-governed

The database request path does not carry the KMS key on every read/write. Firestore checks key availability asynchronously and performs cryptographic operations through its service integration. Your application should therefore treat KMS availability as a managed dependency, not as a per-request library call.

4. Key unavailability is a database incident, not just a KMS incident

Current Native-mode documentation says Firestore polls Cloud KMS roughly every five minutes. After it detects that the key is unavailable, subsequent reads, writes, and queries can begin failing within about ten minutes with FAILED_PRECONDITION. Import/export operations can fail; index builds and new TTL-policy operations can pause until the key returns. A key can become unavailable because a key version is disabled/destroyed or because Firestore loses permission to use it.

import fs from "node:fs";const policy = JSON.parse(fs.readFileSync("governance/key-state.json", "utf8"));function requireKeyForDatabase() {  if (policy.state !== "AVAILABLE") {    const e = new Error("SIMULATED_CMEK_UNAVAILABLE");    e.code = "FAILED_PRECONDITION";    throw e;  }}for (const op of ["read", "write", "query"]) {  try { requireKeyForDatabase(); console.log(op, "ALLOWED"); }  catch (e) { console.log(op, "DENIED", e.code); }}

5. Rotation: new primary does not mean old version can disappear immediately

When the CMEK primary key version rotates, Firestore re-encrypts the database with the latest primary version. During that process, both old and new versions must remain available. Only after Firestore no longer reports the old version as active should the old version be disabled under your KMS lifecycle policy. Rotation runbooks therefore need a database evidence gate, not merely a KMS “new primary created” event.

6. Backups, clone, restore, and export remain part of key governance

A backup from a CMEK database is encrypted using the database’s encryption mechanism and the primary key version at backup creation. Key rotation does not rewrite the key of an already-created backup. Restore/clone can keep source encryption or, with authorized configuration, select a different encryption type/key. This is why a governance review must include who may restore a CMEK database into a Google-default-encrypted database and who may export data to Cloud Storage.

Encryption controls reduce exposure; they do not enforce purpose limitation. IAM on backup/restore/export operations, bucket governance, retention, deletion policy, and audit evidence remain separate controls.

7. Mandatory local lab: key ownership and failure evidence

{  "database": "(default)",  "mode": "Standard Native",  "encryption": "SIMULATED_CMEK",  "keyOwner": "security-platform",  "servicePrincipal": "firestore-service-agent",  "state": "AVAILABLE",  "rotationGate": "old-version-not-active",  "breakGlassOwner": "incident-commander"}

1. Run the simulator with AVAILABLE; all operations must print ALLOWED.
2. Change state to UNAVAILABLE; all operations must fail with simulated FAILED_PRECONDITION.
3. Restore AVAILABLE and record recovery time in governance/evidence/key-drill.json.
4. Verify no production KMS resource was changed.

This proves the application/runbook reacts to a database-wide encryption dependency. It does not prove Google Cloud propagation timing, actual KMS audit records, or Firestore service behavior; those require a separately approved real-project drill.

Production judgment

Choose CMEK because the threat/compliance model requires customer-controlled key policy, auditability, organization constraints, or external-key ownership—not because “more encryption” sounds safer. Add a key SLO, alerting, break-glass owner, backup policy, rotation evidence, and tested failure response. Client-side encryption is a separate choice for specific sensitive fields and can reduce Firestore query/index capability.

Knowledge check

1. Does CMEK provide client-side encryption?
2. Can you enable CMEK on an existing database in place?
3. What permission does the Firestore service agent need on the KMS key?
4. Why can disabling an old key version immediately after rotation be unsafe?
5. Do IAM/Rules become unnecessary when CMEK is enabled?

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.