<br />

By default, all the data at rest in Cloud Firestore with MongoDB compatibility is encrypted using[Google's default encryption](https://cloud.google.com/security/encryption/default-encryption#googles_default_encryption). Cloud Firestore with MongoDB compatibility handles and manages this encryption for you without any additional action on your part.

If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK) for Cloud Firestore with MongoDB compatibility. Instead of Google managing the encryption keys that protect your data, your Cloud Firestore with MongoDB compatibility database is protected using a key that you control and manage in[Cloud Key Management Service (Cloud KMS)](https://cloud.google.com/kms).

This page describes CMEK for Cloud Firestore with MongoDB compatibility. For more information about CMEK in general, including when and why to enable it, see the following Cloud KMS documentation:

- [Customer-managed encryption keys (CMEK)](https://cloud.google.com/kms/docs/cmek)
- [Best practices for using CMEKs](https://cloud.google.com/kms/docs/cmek-best-practices)

For instructions on performing CMEK-related tasks with Cloud Firestore with MongoDB compatibility, see[Use CMEK](https://firebase.google.com/docs/firestore/enterprise/use-cmek).
| **Note:** For information about access to this release, see the[access request form](https://docs.google.com/forms/d/e/1FAIpQLSfKs8wJf4IXu1NizvfyU2vT59JDbdPvkehMVZ2ab5l_aDLIIA/viewform?resourcekey=0-O15dlRFvA0JIDmh6VFUEcA).

## Features

- **Data control**: CMEK lets you manage the KMS key. You can rotate, disable, and destroy the key used to encrypt the data at rest in your Cloud Firestore with MongoDB compatibility database.
- **Performance** : CMEK does not impact the[Cloud FirestoreSLA](https://firebase.google.com/terms).
- **Auditability** : If you[enable audit logging for Cloud KMS](https://cloud.google.com/logging/docs/audit/configure-data-access#config-console-enable), all the operations on the key are logged and viewable inCloud Logging.
- **Organization policy constraints** : You can use[CMEK organization policy constraints](https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints)to specify encryption compliance requirements for Cloud Firestore with MongoDB compatibility databases in your organization.

## Pricing

Cloud KMS charges for the cost of the key and any cryptographic operations performed using that key. For more information, see[Cloud KMS pricing](https://cloud.google.com/kms/pricing).

You are billed for the operation costs when Cloud Firestore with MongoDB compatibility asks the Cloud KMS key to perform an encryption or decryption operation. Encryption or decryption operation by the customer-managed key occurs every 5 minutes and is not synchronized with database requests. Costs are generally low, given the expected number of cryptographic operations generated by Cloud Firestore with MongoDB compatibility. Costs for Cloud Audit Logs are an additional expense, but is also expected to be generally low, given the expected number of cryptographic operations.

There are no additional Cloud Firestore with MongoDB compatibility costs for using CMEK-protected database and the[Cloud Firestore with MongoDB compatibility pricing](https://firebase.google.com/pricing)continues to apply.

If you revoke your key to a database, storage cost will be charged based on the size of the last day that the key was available. You will continue to incur storage costs at that database size until the database is deleted or the key becomes available again.

## What is protected with CMEK

When you create a Cloud Firestore with MongoDB compatibility CMEK-protected database, your Cloud KMS key is used to protect data at rest. This includes data that you store on a disk or a flash drive, including indexes and backups. Some exceptions apply. The following data types are encrypted with Google default encryption and not by the CMEK key:

- Data in transit or in memory
- Database metadata

## How an unavailable key status is handled

Encrypt and decrypt operations are not issued on every data request. Instead, the Cloud Firestore with MongoDB compatibility system polls Cloud KMS every 5 minutes to check if the key is still available and then performs encrypt and decrypt operations if the key is available.

If the system detects that the key is unavailable, within 10 minutes any subsequent calls to the Cloud Firestore with MongoDB compatibility database, including reads, writes, and queries, return a`INVALID_ARGUMENT`error with the following message:  

    The customer-managed encryption key required by the requested
    resource is not accessible.

If the database has[time-to-live (TTL) policies](https://firebase.google.com/docs/firestore/enterprise/ttl), and if any expiration times get exceeded while the key is unavailable,[data deletion by TTL](https://firebase.google.com/docs/firestore/enterprise/ttl#ttl_deletion)will be delayed until the key gets reinstated. If the database has long-running operations in progress, they will be affected as follows:

- [Index build](https://firebase.google.com/docs/firestore/enterprise/indexing#index_build_time)operations, and operations[enabling new TTL policies](https://firebase.google.com/docs/firestore/enterprise/ttl#ttl_policy_enablement_duration)will stop making progress. The stopped operations will be retried if the key gets reinstated.

Keys are considered unavailable in any situation that intentionally disallows Cloud Firestore with MongoDB compatibility from accessing the key. This includes:

- [Disabling](https://cloud.google.com/kms/docs/enable-disable#disable)or[destroying](https://cloud.google.com/kms/docs/destroy-restore)the in-use key version. Be careful when destroying a key version, because this[can cause unrecoverable data loss](https://cloud.google.com/kms/docs/destroy-restore#understand-risks).
- [Removing permission](https://cloud.google.com/kms/docs/iam#revoking_access_to_a_resource)to access the key from the Cloud Firestore with MongoDB compatibility service account.

If the key is reinstated, the polling operation detects that the key is available again. Access is re-enabled, usually within minutes, but it can take up to a few hours in rare cases. Note that some operations on Cloud KMS keys, such as disabling or destroying a key, can take up to[3 hours](https://cloud.google.com/kms/docs/consistency)to propagate. Cloud Firestore with MongoDB compatibility doesn't detect any changes until after they take effect in Cloud KMS.

Reinstatement of a key involves the following, depending on the situation:

- [Re-enabling](https://cloud.google.com/kms/docs/enable-disable#enable)a disabled key version.
- [Restoring](https://cloud.google.com/kms/docs/destroy-restore#restore)a destroyed key version. Before being permanently destroyed, a key version is scheduled for destruction. You can only restore a key during the period when a key version is scheduled for destruction. You cannot restore a key that has already been permanently destroyed.
- [Re-granting](https://cloud.google.com/kms/docs/iam#granting_roles_on_a_resource)theCloud Firestoreservice agent permission to access the key.

| **Warning:** Don't let your key become unavailable for longer than seven days. CMEK-protected databases with keys unavailable for more than 7 days may be deleted. In the event of a key being unavailable, to preserve data beyond the seven days limit, we recommend that you enable backups for your Cloud Firestore with MongoDB compatibility CMEK database with the required retention period. Before you revoke the key, verify a backup has been created, as a valid key is required for backup creation. Additional charges apply for backups. For backup pricing details, see[Cloud Firestore with MongoDB compatibility pricing](https://firebase.google.com/pricing).

## Key rotation considerations

When you rotate the CMEK key, Cloud Firestore with MongoDB compatibility re-encrypts the database with the latest primary version of the CMEK key. During the re-encryption process, keep both the earlier and the new key version available. Once re-encryption finishes, disabling or deleting the earlier versions of the CMEK key won't disable access to the database since it's encrypted with the new primary key version.

You can also view the key versions that are being used to protect a database. For more information, see[View the key in use](https://firebase.google.com/docs/firestore/enterprise/use-cmek#view-key).

## External key considerations

When you use a Cloud EKM key, Google has no control over the availability of your externally-managed key in the external key management partner system.

If an externally-managed key is unavailable, Cloud Firestore with MongoDB compatibility continues to support full database operations using a cached version of the key, for up to one hour.

After an hour, if Cloud Firestore with MongoDB compatibility is still unable to connect with Cloud KMS, Cloud Firestore with MongoDB compatibility begins taking the database offline as a protective measure. Calls to the database will fail with a`INVALID_ARGUMENT`error that includes additional details.

See the[Cloud External Key Manager documentation](https://cloud.google.com/kms/docs/ekm#considerations)for more considerations when using external keys.
| **Caution:** If a database remains disabled for more than 7 consecutive days, Cloud Firestore with MongoDB compatibility might automatically delete it. To avoid permanent data loss, don't leave external keys in an inaccessible state for an extended time.
| **Warning:** If an external key is deleted and cannot be recovered, any Cloud Firestore with MongoDB compatibility database encrypted with that key becomes permanently inaccessible.

## Backup and restore

A backup uses the same encryption mechanism as the database from which you created it. When a CMEK-protected Cloud Firestore with MongoDB compatibility database creates a backup, it encrypts the backup with the primary key version used at the time of backup creation.

Cloud Firestore with MongoDB compatibility creates the first backup of a CMEK database after 24 hours pass from the moment when you enable backup schedules.
| **Note:** Once the backup is created, you can't modify its key and key version, even if you rotate the Cloud KMS key.

For more information about Cloud Firestore with MongoDB compatibility backups, see[Back up and restore data](https://firebase.google.com/docs/firestore/enterprise/backups).

A database restored from a backup uses the same encryption mechanism as the backup by default. When you restore a database, you can specify a different encryption type in one of the following ways:

- Restore to a CMEK database with a newly specified key.
- Restore to a non-CMEK database that uses[Google's default encryption](https://cloud.google.com/security/encryption/default-encryption#googles_default_encryption).
- Restore to a database that uses the same encryption as the backup.

For more information about restoring a Cloud Firestore with MongoDB compatibility database from a backup, see[Restore data from a database backup](https://firebase.google.com/docs/firestore/enterprise/backups#restore_data_from_a_database_backup). For more information about restoring a CMEK-protected Cloud Firestore with MongoDB compatibility database from a backup, see[Restore a CMEK-protected database](https://firebase.google.com/docs/firestore/enterprise/use-cmek#restore-cmek-db).

## Clone

By default, a database cloned from another database uses the same encryption mechanism as the source database. When you clone a database, you can specify a different encryption type in one of the following ways:

- Clone to a CMEK database with a newly specified key.
- Clone to a non-CMEK database that uses[Google's default encryption](https://cloud.google.com/security/encryption/default-encryption#googles_default_encryption).
- (Default) Clone to a database that uses the same encryption as the source database.

For more information about cloning a Cloud Firestore with MongoDB compatibility database, see[Clone a database](https://firebase.google.com/docs/firestore/enterprise/use-pitr#clone). For more information about cloning a CMEK-protected Cloud Firestore with MongoDB compatibility database, see[Clone a CMEK-protected database](https://firebase.google.com/docs/firestore/enterprise/use-cmek#clone-cmek-db).

## Key tracking

You can use key tracking to view resources, for example, Cloud Firestore with MongoDB compatibility databases, that a key protects. For more information about key tracking, see[View key usage](https://cloud.google.com/kms/docs/view-key-usage).

## CMEK and key availability

When keys are unavailable or disabled, be aware of the following behaviors that can occur in CMEK-enabled databases:

- You can delete a CMEK database that has unavailable keys.

- When you create a CMEK-enabled database, disabled keys don't show on the list of available keys in the Google Cloud console. If you manually input a disabled key, the database creation process will fail with a`INVALID_ARGUMENT`error 400.

## Limitations

- You can't change a key for a CMEK-protected database. You can rotate, enable, and disable keys.

- You can't enable CMEK on existing databases. You can enable CMEK only on new databases, and you must enable it when you create the database. To migrate data in an existing non-CMEK database to a CMEK-protected database, export your data and then import data to a new CMEK-protected database. You can also restore or clone data from a non-CMEK database to a CMEK database.

- Cloud Firestoresupports a limited number of CMEK-protected databases.

## What's next

- [Learn how to use CMEK with Cloud Firestore with MongoDB compatibility](https://firebase.google.com/docs/firestore/enterprise/use-cmek).