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.
For a step-by-step guide to using CMEK with AlloyDB, see Use CMEK.
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.
Features
- 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.
Pricing
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
AlloyDB uses your Cloud KMS key to protect data at rest in the following ways:
- If you enable CMEK on a cluster, then AlloyDB uses your key to encrypt all of your cluster's data in storage.
- If you specify a CMEK configuration when creating an on-demand backup, then AlloyDB uses your key to encrypt that backup.
- If you enable CMEK with your cluster's continuous or automated backup configuration, then AlloyDB uses your key to encrypt your ongoing backups.
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 near the data that it encrypts.
AlloyDB encrypts each DEK with a key encryption key (KEK) that's 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.
Enable CMEK
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
Encrypter/Decrypter
(roles/cloudkms.cryptoKeyEncrypterDecrypter) role to a Google-managed
AlloyDB service
account.
For detailed instructions, refer to Use CMEK.
Manage keys
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.
Use and manage external keys
As an alternative to using keys that reside on Cloud KMS, you can use keys residing with a supported external key management partner. To do this, use Cloud External Key Manager (Cloud EKM) to create and manage external keys, which are pointers to keys that reside outside of Google Cloud. For more information, see Cloud External Key Manager.
After you create an external key with Cloud EKM, you can apply it to a new AlloyDB cluster by providing the ID of that key when creating the cluster. This procedure is the same as applying a Cloud KMS key to a new cluster.
You can use Key Access Justifications as part of Cloud EKM. Key Access Justifications lets you view the reason for each Cloud EKM request. Additionally, based on the justification provided, you can automatically approve or deny a request. For more information, see Overview.
Google lacks control over the availability of keys in an external key management partner system.
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.
Logging
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.