Encryption Keys, Cloud KMS and Data Protection

Use cases for encryption keys in Google Cloud are decided by who owns the key encryption key (KEK) that protects data. Google-managed encryption keys (GMEK), also called Google default encryption, are owned and managed by Google with no customer action. Customer-managed encryption keys (CMEK) are created and managed by the customer in Cloud Key Management Service (Cloud KMS) (opens in a new tab), while customer-supplied encryption keys (CSEK) are key material supplied directly by the customer.

1.1Google-Managed Keys for Automatic Default Protection

Google-managed encryption keys (GMEK) are the automatic baseline where Google owns and manages the symmetric KEKs that protect customer data at rest. Services such as Filestore (opens in a new tab) encrypt customer content at rest by default, so the customer takes no action to enable or manage keys. Data flows from the service to Google-managed keys for encrypt and decrypt operations, so ownership, rotation, and availability stay entirely on the Google side of the trust boundary. Choose GMEK when operational simplicity matters most and there is no compliance requirement to manage location, rotation, permissions, or audit logs.

1.2Customer-Managed Keys for Control and Compliance Needs

Customer-managed encryption keys (CMEK) are Cloud KMS keys that the customer controls and assigns to CMEK-integrated services such as Filestore and Google SecOps. CMEK uses envelope encryption, where the service generates a data encryption key (DEK) to encrypt the data and the customer's KEK in Cloud KMS wraps, or encrypts, that DEK. Because the service depends on Cloud KMS to unwrap the DEK on every access, revoking or disabling the CMEK blocks the service from reading, writing, ingesting, or processing data.

CMEK gives control that GMEK does not, including choice of protection level, location, rotation, permissions, boundaries, and auditability:

• Protection level, including software keys, hardware keys in an HSM cluster, and external keys in Cloud External Key Manager (Cloud EKM)
• Location of the key ring and key, which must be in the same location as the protected resource
• Rotation schedule to limit the impact of a potential compromise
• Usage and access permissions granted to service accounts
• Cryptographic boundaries for where keys can be used
• Audit logs for key use and lifecycle control, including disable, destroy, and delete

Choose CMEK when compliance, governance, or security policy requires authority over rotation, location, access, and auditability. Cloud KMS Autokey fits teams that want CMEK control without pre-provisioning every key ring, key, and service account, because Autokey generates them on demand during resource creation.

1.3Customer-Supplied Keys for Direct Key Supply

Customer-supplied encryption keys (CSEK) are the third category where the customer supplies the raw key contents for protecting data. CSEK keeps key supply on the customer side of the trust boundary rather than having Google own the keys or having the customer manage keys inside Cloud KMS. This increases operational burden because the customer must supply and protect the key material. Support depends on the service, and Cloud SQL supports CMEK but does not support CSEK, so a Cloud SQL instance that needs customer control must use a Cloud KMS key. Choose CSEK only when a service explicitly supports it and the use case specifically requires holding the raw key.

1.4Choosing an Option and Enforcing CMEK With Policy

The three options differ by ownership, management effort, and control, and organizations can enforce the CMEK choice with policy. The constraint constraints/gcp.restrictNonCmekServices requires listed services to use CMEK, so a new instance cannot be provisioned without selecting a key, while constraints/gcp.restrictCmekCryptoKeyProjects restricts which projects can supply those keys.

Setting up CMEK follows an ordered dependency where the key must exist and be accessible before the protected resource is created:

1. Create key ring and key: Create a Cloud KMS key ring and symmetric key in the same location as the future resource.
2. Grant access: Grant the service's service account permission to use the key for encrypt and decrypt operations.
3. Create new resource with the key: Create a new instance and select the Cloud KMS key, which can only be enabled on a new instance, not added to an existing one.
4. Operate and rotate: Optionally set a rotation schedule and monitor logs for unavailable keys.

This control creates responsibility. Disabling a key in active use can cause permanent data loss. After rotation begins, wait two weeks before disabling or destroying the previous version, and if access is lost, data is deleted after 30 days while full recovery after re-enabling can take up to two weeks.

The role of Cloud Key Management Service (Cloud KMS) is to let customers own and control the keys that protect stored data, instead of relying on automatic Google-owned encryption. Google-owned and Google-managed encryption protects all stored data automatically with no setup, while Customer-Managed Encryption Keys (CMEK) in Cloud KMS provide stronger control, visibility, and compliance. Only CMEK uses Cloud KMS keys that can be managed and audited.

2.1Default Encryption Compared With Customer-Managed Encryption

Google-owned and Google-managed default encryption is the automatic protection applied to data at rest using the AES-256 standard. Keys are held in Keystore, Google Cloud's internal key management system, with cryptographic modules validated to FIPS 140-3 Level 1. Google automatically manages rotation and keeps a primary key version for new encryptions plus a limited number of older versions for decryption. The customer cannot view keys, review usage logs, or isolate data to a unique key, and data from multiple customers might share the same KEK.

Customer-Managed Encryption Keys (CMEK) move key ownership to the customer in Cloud KMS and support unlimited key versions per key. Using Cloud KMS for CMEK adds cost based on active key versions and cryptographic operations, with no minimum purchase required. CMEK supports goals such as owning keys and controlling location and destruction, controlling access through Identity and Access Management (IAM), setting rotation, importing external key material, enforcing policy, logging access, selectively deleting data by destroying its key through crypto-shredding, and meeting regulations that require customer control.

2.2Key Rings, Keys, and Key Versions in Cloud KMS

A key hierarchy in Cloud KMS moves in order from location to operation: a key ring holds one or more keys, and each key performs work through its key versions. A key ring is a container that groups keys under one location and one Google Cloud project, called the key project, which must have Cloud KMS enabled. The key ring sets the location boundary for every key it holds, so the key ring location must correspond to the location of the service that will use the keys.

A key is the named resource that a cloud service uses to encrypt and decrypt its data. After configuration, the service sends encrypt or decrypt requests to Cloud KMS, Cloud KMS uses the key to perform the operation, and the service never stores the key alongside the data. A key version holds the actual cryptographic material that performs each operation, and the primary version is the version used for new encryption. Key Access Justifications (opens in a new tab) builds on versions by generating a justification code for each operation on an enrolled key, so administrators can view, approve, or deny access. If Cloud HSM (opens in a new tab) keys are used, the service location must match the Cloud HSM key location exactly for regional, dual-regional, and multi-regional locations.

2.3How CMEK Integration Works With Data Services

A CMEK integration is server-side encryption in a supported service that uses a Cloud KMS key instead of Google default encryption. After setup, encryption and decryption are handled by the service's service agent, so access to the resource feels the same as with default encryption and the end user needs no direct access to the key. The service agent depends on having the CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the CMEK. If that role is revoked, or if the key is disabled or destroyed, the service can no longer decrypt its data, and some services can suffer permanent data loss.

Manually enabling CMEK follows an ordered workflow where the key and its permission must exist before the protected resource can use them:

1. Create or choose a key ring: Create a Cloud KMS key ring near the resources to protect, in the same project or a separate project for separation of duties.
2. Create or import the key: Create or import a Cloud KMS key in that key ring to serve as the CMEK.
3. Grant the service agent access: Grant the service's service account the CryptoKey Encrypter/Decrypter IAM role on the CMEK.
4. Configure the resource to use the CMEK: Select the CMEK when creating the resource, such as a BigQuery table protected at rest by that key.

Cloud KMS Autokey simplifies this integration by generating key rings and keys on demand during resource creation and automatically granting the service agent the required roles. Autokey keys follow best practices for location alignment, specificity, hardware protection, rotation, and separation of duties. Key usage tracking in Cloud KMS then shows which resources, projects, and products depend on each key, so administrators can detect unexpected use and plan rotation safely.

2.4Rotation, Replacement, and Destruction of Keys

Key lifecycle management is the process of creating, rotating, replacing, disabling, and destroying keys and versions over time. Rotating a key creates a new key version and makes it the primary version for all new encryption, but previous versions remain enabled so existing data can still be decrypted. Rotation alone does not re-encrypt existing data and does not disable older versions, so data keeps the version specified at creation until it is decrypted and re-encrypted.

Replacing a key moves protection to a whole new key and requires migration before the old key is disabled:

1. Replace the bucket default: Check which buckets use the old key as the default and replace it with the new key.
2. Update ongoing operations: Inspect code and configurations for requests that name the old key, then update them to use the new key.
3. Re-encrypt existing objects: Identify objects encrypted with the old key and use the Rewrite Object method, using Storage batch operations for millions or billions of objects.
4. Disable the old key: Disable all versions of the old key only after re-encryption, then monitor logs for failures caused by unavailable versions.

The choice between disabling and destroying controls whether access can be restored:

Encryption in transit and encryption at rest protect data in two different states, and Google Cloud encrypts both states by default. Encryption in transit protects data while it moves across networks, while encryption at rest protects data while it is stored on disks, snapshots, and images. Moving data can be intercepted on the network, while stored data can be exposed if a disk, backup, or snapshot is accessed without permission.

3.1How Encryption in Transit Protects Moving Data

Encryption in transit is protection applied to data during transmission between services and systems, using secure transport protocols such as Transport Layer Security (TLS). In Dataflow, for example, traffic flows from workers to Google APIs like Cloud Storage, BigQuery, or Pub/Sub, and TLS keeps that moving data unreadable so interception does not expose pipeline content. Dataflow workers run on managed virtual machines that receive public IP addresses by default, which increases network exposure even though transit encryption stays active.

Administrators can control the path that transit traffic takes by keeping it inside the private network and inside a trust boundary. A Virtual Private Cloud (VPC) subnet with Private Google Access lets workers without public IPs route traffic to Google services internally, while VPC Service Controls (VPC-SC) creates a perimeter with protected data inside and external resources outside, so data cannot be copied outside even by users with valid credentials. The secure pattern is ordered: disable public IPs on workers with --usePublicIps=false, enable Private Google Access on the subnet, and place pipelines inside a VPC Service Controls perimeter with dedicated subnets and strict firewall rules.

3.2How Encryption at Rest Protects Stored Data

Encryption at rest is protection applied to data stored on persistent media using the Advanced Encryption Standard (AES). This protection covers worker boot disks, data disks, disk clones, machine images, and standard and instant snapshots, so stored blocks remain unreadable without the key. Protection flows from a source disk to its clones and snapshots, so the key rules for the source affect its copies, and snapshots must use the same key as the source disk.

Three key management options provide different levels of customer control for disk encryption (opens in a new tab):

The table shows that Persistent Disk offers the most key choices, while Hyperdisk and Local SSD are more limited. Local SSD disks support only Google-owned and managed keys, and Hyperdisk volumes cannot use CSEKs. Choose Google-owned keys for simplicity, CMEKs in Cloud Key Management Service (Cloud KMS) (opens in a new tab) for customer control, and CSEKs only where supported and explicitly required.

3.3Ownership and Rotation That Limit Key Compromise

Key ownership for stored data determines who manages AES keys and who controls rotation over time. Google-owned and managed keys require no customer action, and Compute Engine rotates those keys on a yearly basis to limit the impact of compromise. Customer-managed encryption keys (CMEK) are created and managed in Cloud KMS, and Google recommends enabling automatic rotation so the key version changes on schedule. Cloud KMS Autokey simplifies CMEK use by generating key rings and keys on demand during resource creation and granting service agents the required IAM roles.

Network controls mainly strengthen transit protection, while key controls add assurance for stored data. Customer-supplied encryption keys (CSEK) are deprecated for Compute Engine, so new designs should use Google-owned keys or CMEKs. CMEK adds customer control over at-rest keys, but it does not turn on encryption itself because Google already encrypts both transit and stored data by default.

Key Facts

• Google-managed encryption keys (GMEK) are the automatic default where Google owns and manages KEKs, while CMEK keys are customer-owned in Cloud KMS and CSEK keys are raw material supplied by the customer.
• Envelope encryption wraps a data encryption key (DEK) with a key encryption key (KEK), and a CMEK-integrated service depends on Cloud KMS to unwrap the DEK on every access.
• A Cloud KMS key ring sets the location boundary for its keys, a key is the named resource used by a service, and a key version holds the cryptographic material with a primary version used for new encryption.
• Rotating a key creates a new primary version without re-encrypting old data, disabling a version reversibly blocks decryption, and destroying a version permanently prevents decryption through crypto-shredding.
• Transport Layer Security (TLS) protects data in transit from interception, while Advanced Encryption Standard (AES) protects data at rest, with Persistent Disk supporting all three key types and Local SSD supporting only Google-owned keys.