Managing Google Cloud Encryption and Confidential Computing

1.1Google Default Encryption Baseline

Google default encryption is automatic protection for customer data that requires no key configuration. Data moving to Google Cloud is protected in transit with Transport Layer Security (TLS) before transmission, and data is protected at rest once stored. Keys for this baseline are Google-owned and Google-managed keys that Google creates, stores, protects, and operates, and those keys are FIPS 140-2 compliant.

The ownership boundary for default encryption places both data and keys on the Google side of the trust boundary. Workloads therefore receive baseline confidentiality without managing a key ring, key versions, or rotation schedules. Choose Google default encryption (opens in a new tab) when organizational or regulatory requirements accept Google key ownership and do not require customer-controlled rotation, destruction, or external custody.

1.2Customer-Managed Control with CMEK

Customer-managed encryption keys (CMEK) (opens in a new tab) are customer-owned keys in Cloud Key Management Service (Cloud KMS) that replace Google key control for data at rest. With CMEK, the customer owns a CryptoKey in Cloud KMS, and the storage or compute service depends on that key for every encrypt and decrypt operation. The customer controls generation, use, rotation, and destruction, but also assumes responsibility for key availability and recovery.

CMEK enforcement combines separation of duties with Identity and Access Management (IAM) and service defaults. Key administration can live in a dedicated CMEK project separate from the data project, while service agents receive only encrypt and decrypt rights on the key. Decide whether to use CMEK before creating an Assured Workloads folder, because deleting an in-use CMEK key can make data impossible to access or recover.

1.3External Custody with Cloud EKM and Key Access Justifications

Cloud External Key Manager (Cloud EKM) is a Cloud KMS key type where key material lives in an external key manager outside Google Cloud. The Google service stores only encrypted data, so no decryption can succeed without a request flowing from the Google service to the external manager and back. Choose Cloud EKM when sovereignty, jurisdictional isolation, or regulatory mandates require the customer or an external partner to retain custody and the ability to deny access.

Key Access Justifications (KAJ) adds per-request governance by requiring Google systems to attach a justification code to every operation on an enrolled Cloud KMS key. A key policy can allow or deny access based on that code, and audit logs record the code for later review. Common codes include CUSTOMER_INITIATED_SUPPORT, GOOGLE_INITIATED_SERVICE, GOOGLE_RESPONSE_TO_PRODUCTION_ALERT, GOOGLE_INITIATED_REVIEW, THIRD_PARTY_DATA_REQUEST, REASON_NOT_EXPECTED, and REASON_UNSPECIFIED, and governance should treat the last two as missing context rather than verified purpose.

2.1Protection Levels and Execution Environments

Protection level in Cloud KMS is the setting that fixes where cryptographic operations run for a CryptoKey version. The level is set in versionTemplate.protectionLevel at creation and cannot be changed afterward, so isolation must be selected before the key protects data. Changing isolation later requires creating a new key with a different level.

SOFTWARE protection means operations run in software in the Cloud KMS service environment and provides baseline protection acceptable for lower-risk use cases. Hardware Security Module (HSM) protection means operations run inside a Google-managed hardware security module and provides a higher level of security. EXTERNAL and EXTERNAL_VPC mean operations run in an external key manager over the internet or over a Virtual Private Cloud (VPC) network, with key material staying outside Google and support limited to symmetric encryption and asymmetric signing.

2.2Region Matching and Resilience for Keys

KeyRing location in Cloud Key Management Service (Cloud KMS) (opens in a new tab) controls replication and failure isolation for key metadata. A multiregion or global KeyRing replicates metadata across areas and avoids a single-region point of failure, while a single-region KeyRing keeps keys local to one region. That resilience choice directly affects service integration because not every service can use a multiregion key.

Cloud SQL (opens in a new tab) requires the Cloud KMS key version and the instance to be in the same region, and a multiregion or global key causes the instance create request to fail. The key can live in the same project or a separate project as long as location matches. For EKM keys, resilience depends on the EkmConnection having redundant resolvers, because an unreachable external key can suspend a Cloud SQL instance for hours, with validation taking up to 10 minutes to restore access after the key returns.

2.3Permissions, Quota, and Compliance Evidence

CMEK integration connects a Google Cloud service, its per-product service account, and a specific Cloud KMS key version through IAM. The service account must hold the cloudkms.cryptoKeyEncrypterDecrypter role on the key, and operations fail when that grant is missing. When the key lives in a different project and Virtual Private Cloud Service Controls is enabled, the key-hosting project must also be added to the security perimeter.

Every cryptographic call flows from the using service to the Cloud KMS API, so quota and key state affect performance and uptime. Services such as Google Kubernetes Engine call the API on every operation for application-layer secrets encryption, which requires confirming enough quota before enabling the feature. For compliance, Cloud KMS maps key-protection controls to NIST SP 800-53 SC-12 and SC-13, Security Command Center flags keys that do not follow recommended practices, and Cloud Monitoring alerts on lifecycle events such as keys scheduled for destruction.

3.1Revocation by Disabling and Destruction by Crypto-Shredding

Revocation by disabling is the reversible act of turning off a key version in Cloud KMS so services can no longer use it. Google Cloud services that use customer-managed encryption keys (CMEK) (opens in a new tab) call Cloud KMS on each data operation, so when Cloud KMS reports the key as disabled or destroyed, dependent data becomes inaccessible. Disablement can take up to three hours to propagate to dependent services, while permission changes usually propagate much faster.

Scheduled destruction is the irreversible lifecycle that permanently removes a key version's ability to perform operations for crypto-shredding. The lifecycle moves through ordered states with a built-in recovery window:

1. Request destruction: The version moves from ENABLED or DISABLED to SCHEDULED FOR DESTRUCTION for its configured duration.
2. Restoration window: The version remains restorable only while SCHEDULED FOR DESTRUCTION.
3. Destroyed state: After the duration passes, the version moves to DESTROYED, logical deletion begins, and the customer cannot recover the material.
4. Residual retention: Key material can remain in Google systems for up to 45 days while deletion completes across storage layers.

Destruction permanently disables the version and stops billing for it, while deletion only removes the record from listings and cannot substitute for destruction. Deleted CryptoKey names cannot be reused, and destroying all active versions does not stop automatic rotation unless rotation is explicitly disabled.

3.2Manual and Coordinated External Keys

Cloud External Key Manager (Cloud EKM) (opens in a new tab) keys are pointers to key material that stays in a supported external manager outside Google Cloud. For symmetric encryption, data flows first from Cloud KMS to its internal key material for initial encryption, then from Cloud KMS to the external manager for a second wrapping layer, then back to Cloud KMS as ciphertext that requires both materials to decrypt. Because both sides are required, loss of access on either side means data cannot be decrypted.

Manually managed keys require the administrator to create the external key, grant the Google project access in the external system, create the Cloud EKM version with that URI or key path, and maintain rotation and destruction on both sides. Coordinated keys use an EKM connection over VPC with Cloud KMS management mode, so creation, rotation, and destruction initiated in Cloud KMS are forwarded to the external manager. A destroyed Cloud EKM version cannot be recreated even with the same URI or key path.

3.3Automatic Rotation and Version Transition

Automatic rotation creates a new primary key version on a schedule so new data encryption keys are wrapped with the new version. Only symmetric ENCRYPT_DECRYPT keys with the GOOGLE_SYMMETRIC_ENCRYPTION algorithm and Google-generated material can rotate automatically inside Cloud KMS. Keys with imported bring-your-own-key material require external automation to generate and import each new version on time.

Rotation changes only the primary version for new encryptions, while prior enabled versions remain required to decrypt existing data. The effect depends on how each service manages its data encryption keys:

4.1Client-Side Envelope Encryption and Tokenization

Client-side envelope encryption protects payloads inside the customer environment before transmission to Google Cloud. The application encrypts sensitive fields locally with a data encryption key (DEK) using Google Tink, then wraps that DEK with a symmetric CMEK key encryption key (KEK) managed in Cloud KMS and generated in Cloud HSM. Google storage and transport layers then handle only ciphertext plus the wrapped DEK, and plaintext appears only where KEK use is explicitly authorized.

Data flows from the customer application to BigQuery through an ordered envelope sequence. First, the application obtains a fresh DEK locally or from Cloud HSM. Then, the application encrypts the field with the DEK before data leaves the customer trust boundary. Next, the application calls Cloud HSM to wrap the DEK with the KEK. Finally, the ingestion path writes ciphertext to a BigQuery data table and the wrapped DEK to a separate key table, and authorized reads unwrap the DEK with the KEK before decrypting the column.

Field-level tokenization with Sensitive Data Protection replaces personally identifiable information with tokens before storage. An ingestion pipeline reads raw data from Cloud Storage, passes it through detectors and a Dataflow pipeline, and writes tokenized output to a BigQuery warehouse. Structured data uses record transformations by field, unstructured data uses infoTypes detection, and re-identification requires both access to the tokenized table and authorization for the wrapping key plus the Fine-Grained Reader role for the column policy tag.

4.2Key Management Models for Data at Rest

Key management models for data at rest define who owns the key encryption key, where material lives, and who controls rotation and audit. Google Cloud uses envelope encryption where a KEK wraps data encryption keys that directly encrypt data. Choosing Google-managed keys, CMEK, Customer-Supplied Encryption Keys (CSEK), or Cloud EKM determines the cryptographic boundary, overhead, and compliance posture.

Google-owned default encryption (opens in a new tab) is automatic with keys in Keystore using AES-256, with Google rotating most keys and customers unable to view keys or logs. Cloud Key Management Service (Cloud KMS) CMEKs are customer-owned KEKs where the service agent performs operations transparently, and access depends on both IAM permission to the resource and the service agent's encrypter/decrypter role on the key. Cloud KMS Autokey automates provisioning by letting a developer request a key during resource creation, producing AES-256 GCM keys co-located with the resource, rotated yearly, with separation between key users and managers.

4.3Default and Additional Protection for Data in Transit and Data in Use

Default protection for data in transit covers traffic inside Google's production network. Virtual machine (VM)-to-VM traffic within a Virtual Private Cloud (VPC) network and between peered VPC networks is encrypted, and traffic between Google services uses Application Layer Transport Security (ALTS) for authentication, integrity, and encryption. Traffic from the internet or VPC to Google services terminates at the Google Front End, which provides denial-of-service countermeasures and routes traffic onward.

Additional protection is required when traffic crosses trust boundaries or applications need mutual authentication. Cloud VPN uses IPsec to encrypt traffic over VPN connections, while Cloud Interconnect can use MACsec because Interconnect traffic is not encrypted by default. Apigee supports TLS and mutual TLS for API ingress, and Cloud Service Mesh provides mutual TLS for containerized applications on Google Kubernetes Engine and Compute Engine. Protection for data in use requires Confidential Computing, where a Confidential VM uses hardware-based memory encryption so data stays encrypted while processed, with keys held only in dedicated hardware inaccessible to the hypervisor.

5.1Conditional and Version-Aware Lifecycle Rules

Conditional lifecycle rules in Google Cloud Storage (opens in a new tab) are automated bucket rules that pair conditions with actions applied only to matching objects. The condition defines scope, such as objects that reached a required age, objects in a specific storage class that should move to cheaper archival storage, or objects with custom metadata marking sensitivity. The action then transitions storage class or deletes objects whose retention period ended, and Cloud Storage evaluates the rules automatically as new data arrives.

Version-aware lifecycle management extends that logic to versioned objects when Object Versioning is enabled. One object name can have one live generation plus zero or more archived generations preserved after overwrite or delete. A version-aware rule can keep the live object available while expiring old archived generations after a defined period. Deleting a specific archived generation requires the bucket name, object name, and generation number together, so the live generation is unchanged when the rule targets an archived generation.

5.2Retention Locks, Legal Holds, and Encryption Continuity

Retention Policy with Bucket Lock and Soft Delete are bucket-level guardrails beside lifecycle rules. A Retention Policy prevents deletion or replacement until its duration expires and enforces minimum retention required by law. Soft Delete keeps an object for a recovery window after deletion so it can be restored if a rule or user deletes it too early. Together with Object Versioning, versioning protects against overwrite, Retention Policy enforces must-keep compliance, and Soft Delete protects against must-recover mistakes.

Lifecycle design must map each transition and deletion to a defined retention schedule and evaluate holds first. Archival transitions move objects to Nearline, Coldline, and Archive tiers where the object remains stored and encrypted but with an infrequent-access availability profile. Encryption does not change on transition, but objects protected by CMEK depend on Cloud KMS key availability on every API call. If the key is disabled, destroyed, or denied, the archived object becomes unreadable even though the transition succeeded, while deletion plus key destruction provides strong de-risking through crypto-shredding.

6.1Trusted Execution Environments and Their Properties

A trusted execution environment (TEE) is a secure area inside the processor that protects the confidentiality and integrity of code and data loaded inside it. Confidential Computing completes end-to-end encryption by adding encryption in use to encryption at rest and encryption in transit. Data flows from encrypted storage over an encrypted connection into encrypted memory, is decrypted only inside the processor boundary, and results leave encrypted for storage or transmission.

Four hardware-backed properties work together to protect data in use. Runtime encryption keeps TEE data encrypted in memory so direct reads reveal only ciphertext. Isolation blocks software access from outside the TEE except over defined interfaces. Attestation produces a cryptographically signed report that lets a data owner verify the environment before releasing keys or data. Data lifecycle security extends hardware protection into the processing phase rather than only storage and movement.

6.2Confidential VM, Confidential GKE Nodes, and Confidential Space

Confidential VM (opens in a new tab) is a virtual machine type that uses hardware-based memory encryption to protect data and applications while in use. Supported hardware includes AMD SEV, AMD SEV-SNP, Intel TDX, Arm CCA, IBM Z, IBM LinuxONE, and Nvidia Confidential GPU for accelerated workloads. With Confidential VM, the cloud stack and administrators, BIOS and firmware, and host operating system and hypervisor move outside the trust boundary, while the guest administrator, guest operating system, applications, and data remain inside.

Confidential GKE Nodes (opens in a new tab) run containers as Confidential VMs so container memory is hardware-encrypted and isolated from host and administrator. Configuration can apply at the cluster or node-pool level or at the workload level with a ComputeClass that defines new node attributes and fallback behavior. Confidential Space creates a secure area within a VM with the highest isolation, removing even the guest administrator from the boundary and keeping only measured and attested guest components plus data inside. Choose Confidential VM for VM workloads without redesign, Confidential GKE Nodes for container orchestration, and Confidential Space for multi-party collaboration or regulated workloads where participants do not trust each other or the operator.

6.3Attestation and End-to-End Confidential Workflows

Attestation is the process that proves a Confidential VM instance is legitimate before data is released. The CPU chip supporting the TEE produces a signed attestation report covering bootloader activity, hardware configuration, firmware configuration, and other boot-time events. The report flows to an attestation service for verification, and only after validation does the owner release decryption keys or encrypted data to the TEE.

Reports are signed by a software-based virtual Trusted Platform Module covering boot and kernel integrity, or by hardware roots such as the AMD Secure Processor or Intel TDX module with a Trusted Security Module. For Intel TDX, initial firmware is measured into the Measurement of the Trust Domain and the remaining boot chain into Runtime Measurement Registers. End-to-end designs combine this gate with split trust, where authorization from two independent key management systems is required so no single insider can access data unilaterally, and with federated patterns where collaborators send only aggregated model updates to a TEE server rather than raw records.

Key Facts

• Google default encryption uses Google-owned and Google-managed keys automatically, while customer-managed encryption keys (CMEK) in Cloud Key Management Service (Cloud KMS) give customers control over generation, use, rotation, and destruction.
• A Cloud KMS protection level is fixed in versionTemplate.protectionLevel at creation and cannot be changed, with SOFTWARE running operations in software and HSM running operations inside a hardware security module.
• Disabling a key version makes dependent data temporarily inaccessible and is reversible, while destroying a version permanently removes decryption ability after the scheduled destruction period.
• Cloud External Key Manager (Cloud EKM) keeps key material outside Google Cloud so decryption requires a request to flow from the Google service to the external manager, and a destroyed Cloud EKM version cannot be recreated.
• Confidential Computing adds encryption in use inside a hardware-based trusted execution environment, with Confidential Space also removing the VM guest administrator from the trust boundary.