This page describes customer-managed encryption keys (CMEK) for AlloyDB for PostgreSQL. For more information about CMEK in general, including when and why to enable this feature, see the Cloud KMS documentation.
A self-managed alternative to Google-managed encryption
By default, all data at rest in Google Cloud, including the data in AlloyDB, is protected using Google-managed default encryption. Google Cloud handles and manages this default encryption for you without any additional actions on your part.
If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use CMEK instead. With CMEK, your AlloyDB cluster is protected using a key that you control and manage in Cloud Key Management Service (KMS). Your CMEK key can be a symmetric key or a Cloud HSM key.
- Data access control: Administrators can rotate, manage access to, and disable or destroy the key used to protect data at rest in AlloyDB.
- Auditability: If you enable audit logging for Cloud KMS API in your project, all actions on the key, including those performed by AlloyDB, are logged and viewable in Cloud Logging.
- Performance: Using CMEK introduces no changes to AlloyDB performance.
AlloyDB bills for a CMEK-enabled cluster just like any other cluster; there are no additional AlloyDB costs. For more information, see AlloyDB for PostgreSQL pricing.
You are billed by Cloud KMS for the cost of the key and for encryption and decryption operations when AlloyDB uses the key. For more information, see Cloud Key Management Service pricing.
What is protected with CMEK
In a CMEK-enabled cluster, AlloyDB uses your Cloud KMS key to protect data at rest. This includes all data in a cluster stored on disk.
Some exceptions apply. The following types of data are protected by Google default encryption at rest and not by the CMEK key:
- Operational logs
- Data in transit or in memory
- Cluster metadata
Whether you use Google-managed keys or CMEK, AlloyDB has three layers of encryption:
AlloyDB breaks data at rest into chunks for storage, and encrypts each chunk with an individual encryption key. The key that it uses to encrypt the data in a chunk is called a data encryption key (DEK).
Because of the high volume of keys at Google, and the need for low latency and high availability, AlloyDB stores each DEK key near the data that it encrypts.
Each DEK key is encrypted with a key encryption key (KEK) held by the cluster.
Finally, AlloyDB encrypts the KEK with your cluster's Cloud Key Management Service-based encryption key, which is either a Google-managed key or a CMEK key.
When you rotate the CMEK key, AlloyDB re-encrypts the cluster's KEK with the latest primary version of the CMEK key. Once the KEK's re-encryption finishes, disabling or deleting the old versions of the CMEK key does not disable access to the cluster.
You can also view the key versions that are being used to protect a cluster.
To allow an AlloyDB cluster to use CMEK, you must specify the Cloud KMS key at the time of cluster creation.
AlloyDB is able to access the key on your behalf after
you grant the
Cloud KMS CryptoKey
roles/cloudkms.cryptoKeyEncrypterDecrypter) role to a Google-managed
For detailed instructions, refer to Use CMEK.
Use Cloud KMS for all key-management operations. AlloyDB cannot detect or act upon any key changes until they are propagated by Cloud KMS. Some operations, such as disabling or destroying a key, can take up to three hours to propagate; changes to permissions usually propagate much faster.
After the cluster is created, AlloyDB calls Cloud KMS about every five minutes to make sure that the key is still valid.
If AlloyDB detects that your Cloud KMS key has been disabled or destroyed, an operation to make your cluster's data inaccessible begins immediately. If AlloyDB's calls to Cloud KMS detect that a formerly disabled key has been re-enabled, it restores access automatically.
How an unavailable key status is handled
In rare scenarios, such as during periods when Cloud KMS is unavailable, AlloyDB might be unable to retrieve the status of your key from Cloud KMS.
If your AlloyDB cluster is protected by a key that is enabled at the time at which AlloyDB is first unable to communicate with Cloud KMS, AlloyDB continues to support full cluster operations on a best-effort basis for a period of up to 30 minutes, to minimize the impact of any such incident on your workload.
After 30 minutes, if AlloyDB is still unable to connect with Cloud KMS, AlloyDB begins taking the cluster offline as a protective measure. The data in your AlloyDB cluster remains inaccessible until your cluster can reconnect with Cloud KMS and Cloud KMS responds that the key is active.
Conversely, if your AlloyDB cluster is protected by a key that is disabled at the time at which AlloyDB is first unable to communicate with Cloud KMS, your cluster remains inaccessible until it is able to reconnect to Cloud KMS and you have re-enabled your key.
Backups and restoration
AlloyDB also protects backups with either CMEK or the default Google-managed encryption. If a backup is CMEK-enabled, it is encrypted using the primary version of the KMS key at the time of backup creation. After a backup is created, its key and key version cannot be modified, even if the KMS key is rotated. For more information, see Backing up a cluster.
When you restore a cluster from a backup, the restored cluster defaults to using Google-managed encryption, but you can specify a CMEK key to use instead. To restore a CMEK-enabled backup, both the key and key version that was used to encrypt the backup must be available.
You can audit the requests that AlloyDB sends to Cloud KMS on your behalf in Cloud Logging, if you have enabled audit logging for the Cloud KMS API in your project. These Cloud KMS log entries are visible in Cloud Logging. For more information, see Viewing audit logs for a Cloud KMS key.