Managing encryption at rest, in transit, and in use

Identifying use cases for Google default encryption, customer-managed encryption keys (CMEK), and Cloud External Key Manager (EKM)

Key Management Options and Decision Criteria

Google Cloud provides multiple tiers of encryption key control based on regulatory requirements, operational overhead, and key ownership boundaries:

• Google default encryption encrypts all data at rest automatically without requiring configuration. Google creates, stores, and rotates the keys, making this the best choice for workloads that require baseline protection with zero administrative effort.
• Customer-managed encryption keys (CMEK) use Cloud Key Management Service (Cloud KMS) to let organizations generate, rotate, and revoke their own keys. Choose CMEK when policies mandate granular control over key lifecycles or require immediate access revocation by disabling keys across specific cloud services.
• Customer-supplied encryption keys (CSEK) require the client to supply raw cryptographic keys with every API request to protect Compute Engine disks or Cloud Storage buckets. Choose CSEK when keys must never be stored inside Google Cloud at rest, noting that losing the key makes data recovery impossible.
• Cloud External Key Manager (Cloud EKM) connects Cloud KMS to an external key management system hosted outside Google's infrastructure. Choose Cloud EKM when strict data sovereignty laws or corporate mandates dictate that encryption keys must physically reside on-premises or within a third-party custody solution.

Architectural Dependencies and Service Agents

When using CMEK, Google Cloud services access keys through specialized service agents. The resource owner grants the Cloud KMS CryptoKey Encrypter/Decrypter role to the target service agent account. If an administrator revokes this role or disables the underlying key, the service loses access to the wrapped data keys. For Cloud EKM, traffic flows from Google Cloud to the external partner over the public internet or private VPC connections, making data availability strictly dependent on external system uptime.

Determining when to use software and hardware keys

Key Protection Levels in Cloud KMS

Cloud KMS categorizes keys by their underlying protection level to meet different security and compliance standards:

• Software keys run inside standard software-based cryptographic modules within Google's infrastructure. Choose software keys for low-cost, high-throughput operations such as high-volume application-layer encryption where physical hardware isolation is not required.
• Hardware keys are managed by Cloud HSM, which hosts keys inside FIPS 140-2 Level 3 validated Hardware Security Modules. Choose Cloud HSM when regulatory frameworks explicitly require hardware-backed key protection, tamper-evident boundaries, and non-exportable private key material.

Tradeoffs and Operational Boundaries

Software keys provide the fastest response times and the lowest operational costs. In contrast, Cloud HSM keys enforce hardware isolation directly at the chip level, preventing direct key extraction even during cryptographic operations. Both software and hardware keys share the same Cloud KMS API surface and IAM authorization model, allowing applications to switch between protection levels without changing application logic.

Creating and managing encryption keys for CMEK and EKM (e.g., key rotation and revocation, key import)

Key Hierarchy and Creation

Cloud KMS organizes cryptographic resources in a strict containment hierarchy. A project contains regional or multi-regional key rings, key rings contain crypto keys, and crypto keys contain one or more key versions. Administrators define key rings based on resource location requirements to ensure data and keys remain in the same geographic region.

Project
  └── Key Ring (Location-bound)
        └── Crypto Key (Purpose & algorithm)
              ├── Key Version 1 (Primary for encryption / Enabled)
              └── Key Version 2 (Enabled for decryption only)

Key Rotation, Import, and Lifecycle States

Automated and manual operations dictate how key versions transition through distinct lifecycle states over time:

• Key rotation generates a new primary key version while keeping older versions active to decrypt existing data. Scheduled automatic rotation ensures periodic generation of new versions without breaking access to previously encrypted objects.
• Key import allows organizations to securely wrap and upload on-premises cryptographic material into Cloud KMS using an import job. Choose key import when bringing existing key material into the cloud while preserving specific cryptographic histories.
• Revocation and destruction transitions a key version to a disabled state to instantly cut off cryptographic operations without losing data permanently. Setting a key version to scheduled for destruction initiates a mandatory 24-hour waiting period before permanent, unrecoverable deletion occurs.

Applying encryption methods to various use cases

Encryption in Transit, at Rest, and Envelope Encryption

Google Cloud protects data automatically across network boundaries and storage layers using layered cryptographic controls:

[Plaintext Data] + [Data Encryption Key (DEK)] ──> [Encrypted Data at Rest]
                         │
                         ▼
        [Cloud KMS Key Encryption Key (KEK)] ──> [Encrypted DEK (Stored alongside data)]

• Encryption in transit protects data moving across the public internet and between physical data centers using standard TLS or Google's Application Layer Transport Security (ALTS).
• Envelope encryption protects data at rest by encrypting raw data with a Data Encryption Key (DEK) and then encrypting the DEK with a Key Encryption Key (KEK) managed in Cloud KMS. This model allows fast local data processing with the DEK while maintaining centralized access control over the KEK.
• Client-side encryption encrypts data on the local client machine before sending it over the network to Google Cloud. Choose client-side encryption when workloads require zero-trust guarantees against the cloud provider entirely.

Configuring object lifecycle policies for Cloud Storage

Policy Conditions and Automated Actions

Cloud Storage evaluates object lifecycle management rules to transition storage tiers or remove objects automatically. Policies consist of condition-action pairs evaluated daily against bucket contents. Conditions can match object age, creation date, current storage class, live state, or the number of newer versions in versioned buckets.

[Object in Bucket] ──(Age > 30 Days)──> [Transition to Nearline]
                   ──(Age > 365 Days)─> [Delete Object & Drop Key Association]

Lifecycle Actions and Data Retention Alignment

Common lifecycle actions move objects to colder storage classes or trigger permanent deletion:

• SetStorageClass moves data to Nearline, Coldline, or Archive storage as objects age to optimize costs.
• Delete permanently removes live or noncurrent object versions once retention periods expire.

When combined with CMEK, lifecycle deletion actions permanently release references to wrapped DEKs, ensuring automated alignment between data retention rules and compliance requirements.

Enabling Confidential Computing

Protecting Data in Use with Memory Encryption

Confidential Computing closes the final security boundary by protecting data in use within system memory. Standard systems decrypt data into RAM during active processing, leaving it vulnerable to root users or hypervisor inspection. Confidential Computing uses dedicated hardware features—such as AMD Secure Encrypted Virtualization (SEV) or Intel Trust Domain Extensions (TDX)—to keep system memory encrypted with hardware-generated keys that the hypervisor cannot read.

Deployment Across Compute Engine and GKE

Organizations can enforce memory encryption across standard and containerized workloads:

• Confidential VMs run Compute Engine workloads with hardware-based memory encryption enabled via a single configuration flag at instance creation.
• Confidential GKE Nodes enforce memory encryption across all underlying nodes within a Google Kubernetes Engine cluster.

Choose Confidential Computing when processing highly regulated information, executing multi-party data analytics, or isolating workloads from host-level infrastructure access.