To control and manage the encryption keys that protect your data at rest in AlloyDB for PostgreSQL clusters and backups, you can use customer-managed encryption keys (CMEK) in Cloud Key Management Service (Cloud KMS).
For more information about CMEK in general, including when and why to enable this feature, see the Cloud KMS documentation.
By default, AlloyDB for PostgreSQL encrypts customer content at rest. AlloyDB handles encryption for you without any additional actions on your part. This option is called Google default encryption.
If you want to control your encryption keys, then you can use customer-managed encryption keys (CMEKs) in Cloud KMS with CMEK-integrated services including AlloyDB. Using Cloud KMS keys gives you control over their protection level, location, rotation schedule, usage and access permissions, and cryptographic boundaries. Using Cloud KMS also lets you view audit logs and control key lifecycles. Instead of Google owning and managing the symmetric key encryption keys (KEKs) that protect your data, you control and manage these keys in Cloud KMS.
After you set up your resources with CMEKs, the experience of accessing your AlloyDB resources is similar to using Google default encryption. For more information about your encryption options, see Customer-managed encryption keys (CMEK).
To learn how to use manually created CMEKs to protect your AlloyDB resources, see Use CMEK.
CMEK with Cloud KMS Autokey
You can either create CMEKs manually to protect your AlloyDB resources or use Cloud KMS Autokey. With Autokey, key rings and keys are generated on demand to support resource creation in AlloyDB. Service agents that use the keys for encrypt and decrypt operations are created if they don't already exist and are granted the required Identity and Access Management (IAM) roles. For more information, see Autokey overview.
Features
Data access control: Administrators can rotate, manage access to, and disable or destroy the key that you used to protect data at rest in AlloyDB.
Key management is handled by Cloud KMS. Clusters don't automatically re-encrypt themselves with the newer key version after rotation. Clusters are encrypted by the primary version of the CMEK at the time of cluster creation. To rotate cluster encryption, create a backup and restore the cluster with a newer key version. For more information about backups and recovery, see Data backup and recovery overview.
Auditability: If you enable audit logging for the 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 the same as any other cluster, at no additional AlloyDB charge. 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-owned and Google-managed encryption 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 KMS-based encryption key, which is either a Google-owned and Google-managed encryption key or a CMEK key.
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 the
AlloyDB service
agent.
For detailed instructions, see Use CMEK.
Manage keys
Use Cloud KMS for all key-management operations. AlloyDB can't 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, AlloyDB begins an operation to make your cluster's data inaccessible. 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.
Key unavailability
If you disable the Cloud KMS key that is used to encrypt an AlloyDB cluster, AlloyDB instances belonging to that cluster experience downtime within 30 minutes. Re-enabling the key brings the instances back up.
In infrequent scenarios, such as during periods when Cloud KMS is unavailable, AlloyDB might be unable to retrieve the status of your key from Cloud KMS. In this scenario, 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 temporary outages 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.
Backups and restoration
AlloyDB also protects backups with either CMEK or the default Google-managed encryption. If a backup is CMEK-enabled, it's encrypted using the primary version of the Cloud KMS key at the time of backup creation. After a backup is created, its key and key version can't be modified, even if the Cloud KMS key is rotated. For more information about encrypting backups with CMEK, 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.
Cross-region replication
Because Cloud KMS keys are regional resources, a primary cluster and a cross-region secondary cluster must use different Cloud KMS keys located in their respective regions. The encryption configurations of a primary cluster and its secondary cluster are independent of each other. To protect both clusters with CMEK, create a Cloud KMS key in the primary cluster's region and a separate Cloud KMS key in the secondary cluster's region.
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 View audit logs for a Cloud KMS key.