Control encryption of sensitive data on GKE

In this article, we explore the three states of application data—at rest, in transit, and in use—and detail how Google Kubernetes Engine (GKE) implements encryption mechanisms to protect customer data throughout its lifecycle.

The image outlines the three states of data: Data at Rest, Data in Transit, and Data in Use, along with their descriptions and security considerations.

Data States Overview

Data State	Definition	Examples
Data at rest	Stored on disks, SSDs, databases, or cloud storage, typically dormant	Persistent volumes, database backups
Data in transit	Transmitted across networks using protocols like HTTP(S) or gRPC	API calls, file transfers
Data in use	Actively processed in memory or cache by applications or OS processes	In-memory computations, data analytics

GKE applies encryption by default across all three states to ensure confidentiality, integrity, and compliance.

Encryption at Rest

Google Cloud automatically encrypts all customer data at rest using the Advanced Encryption Standard (AES-256). To meet compliance or key ownership requirements, you can use Cloud Key Management Service (Cloud KMS):

Create, rotate, and manage your own cryptographic keys.
Implement envelope encryption for layered security.
Audit and control key usage with IAM policies.

The image illustrates Google Cloud's encryption process, highlighting encryption at rest and in transit using Cloud Key Management Service and Advanced Encryption Standard.

Note

Customer-managed encryption keys (CMEK) let you maintain full control over key rotation, access policies, and audit logs.

Encryption in Transit

All data exchanged between clients and Google Cloud services is protected by HTTPS (TLS). Key features include:

TLS handshake powered by BoringSSL.
Default support for strong cipher suites and forward secrecy.
Encryption for both user-facing traffic and internal API calls.

This ensures authenticity, integrity, and privacy for every request and response.

Warning

Ensure your clients and services support TLS 1.2 or higher to comply with Google’s security requirements.

Encryption in Use

GKE’s Confidential Nodes leverage Compute Engine Confidential VMs to encrypt VM memory, protecting data during processing.

The image illustrates the concept of GKE Confidential Nodes, highlighting encryption in use and data protection within Compute Engine Confidential VMs.

Enabling Confidential Nodes

Confidential Nodes can be activated at:

Cluster level
- Enable during cluster creation to apply encryption-in-use across all node pools.
- This setting is irreversible for existing and new pools.
Node pool level
- In clusters with Confidential Nodes enabled, toggle per node pool when creating or updating.
- Only selected pools will enforce memory encryption.

The image is a diagram titled "GKE Confidential Nodes," illustrating the concept of encryption in use at the cluster and node-pool levels. It features labeled sections with icons and plus signs, indicating different levels of configuration.

Confidential GKE nodes incur no additional fees beyond standard Confidential VM pricing and produce slightly more detailed startup logs. They are available in regions and zones supporting N2D or C2D machine types.

References

Watch Video

Watch video content