Architecture & Security Guides for Apigee & Enterprise AI Gateways

Apigee X Encryption Architecture: Google-Managed vs. CMEK (with HSM)

Technical Advisory: Data-at-Rest Encryption for Financial Institutions

Executive Summary

This document provides a technical overview of encryption options for Apigee X. While Google Cloud provides robust encryption by default, financial institutions typically opt for Customer-Managed Encryption Keys (CMEK) to meet regulatory mandates. Hardware Security Module (HSM) is a specific protection level within the CMEK management model that provides hardware-backed key material.


1. Encryption Management Models

Google Cloud categorizes data-at-rest encryption into two primary management models. Within the Customer-Managed model, further granularity is provided via Protection Levels.

A. Google-Managed Encryption (Default)

By default, all data stored within Google Cloud is automatically encrypted at rest using keys managed by Google.

“By default, Google Cloud automatically encrypts data when it is at rest using encryption keys that are owned and managed by Google.” Introduction to CMEK (Apigee X)

B. Customer-Managed Encryption Keys (CMEK)

CMEK allows customers to use their own cryptographic keys, managed via Cloud KMS, to protect data in Apigee X.

“If you have specific compliance or regulatory requirements related to the keys that protect your data, you can use customer-managed encryption keys (CMEK).” Introduction to CMEK (Apigee X)


2. Cloud HSM Protection Level

HSM is a Protection Level for an encryption key within the Cloud KMS service, ensuring keys are hardware-backed.

“Cloud HSM keys with the HSM protection level are stored in a Google-owned Hardware Security Module (HSM)… You can use Cloud HSM keys the same way you use Cloud KMS keys.” Cloud KMS Protection Levels


3. Technical Mechanics: Control Plane vs. Runtime

Apigee X partitions encryption between management data (Control Plane) and traffic data (Runtime).

Control Plane Data (Data residency regions)

In the regionalized Apigee control plane, you select two encryption keys for your control plane. This is because some of the components underlying the Apigee control plane are always in a single-region within the control plane location.

  1. One key for control plane data: Protects proxy configuration and analytics storage.
  2. One key for control plane sub-region data: Protects sub-region components (e.g., analytics processing, portals) which are always in a single-region within the control plane location.
    • Nuance: While stored and encrypted by the control plane key, proxy bundles are cached and re-protected by Runtime keys (Disk/Database) during execution on the runtime plane.

Runtime Data (Database vs. Disk)

Runtime data encryption is multi-layered and requires strict isolation.

  1. Runtime Database Key: One key per organization, shared across all sessions.
  2. Disk Encryption Key: Each unique instance/region combination maintains its own key.

    “Each instance/region combination has its own disk encryption key.” About the Apigee encryption keys

  3. Key Ring Separation: Google mandates that different key types reside in separate key rings.

    “Keys of different types must be in separate key rings; disk encryption keys cannot be in the same key ring as your runtime database encryption key.” About the Apigee encryption keys


4. HSM vs. Software CMEK: Trade-offs

Factor Software-backed CMEK Cloud HSM-backed CMEK
Protection Software-based (KMS default) Hardware-backed (FIPS 140-2 L3)
Complexity Low (standard KMS) Low (identical API, requires HSM flag)
Cost (Key/Mo) $0.06 $1.00
Throughput (QPM) ~60,000 (Exempted*) ~30,000 (Strict limit)
Latency Low (Internal Software) Slightly Higher (HSM Cluster Routing)

The “Expensive” Reality: Beyond the ~16x higher monthly key fee, HSM is considered “expensive” due to its hardware-bound throughput quotas. Software-backed keys are often exempted from CMEK integration quotas, whereas HSM keys face hard caps:

Scaling Strategy: “Multi-Key Architecture” (Sharding) To bypass these hardware limits, high-volume institutions use a sharding pattern—distributing workloads across multiple projects or regions to pool quotas (e.g., getting multiple 30k QPM buckets). This is an official recommendation for high-traffic environments.


5. Implementation & Constraints

Gcloud Configuration

CMEK is immutable; it must be assigned at Organization birth.

# Example for provisioning a new Org with CMEK
gcloud beta apigee organizations create \
    --project=PROJECT_ID \
    --runtime-database-encryption-key-name=projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/RING_NAME/cryptoKeys/KEY_NAME

Terraform Implementation

# Apigee Organization Resource
resource "google_apigee_organization" "apigee_org" {
  project_id                           = var.project_id
  runtime_database_encryption_key_name = google_kms_crypto_key.apigee_hsm_key.id
}

# KMS Key with HSM Protection
resource "google_kms_crypto_key" "apigee_hsm_key" {
  name     = "apigee-runtime-hsm-key"
  key_ring = google_kms_key_ring.key_ring.id
  version_template {
    algorithm        = "GOOGLE_SYMMETRIC_ENCRYPTION"
    protection_level = "HSM" # Hardware backing
  }
}

Critical Constraints

  1. Key Deletion: Keys cannot be deleted instantly. They can be scheduled for destruction or disabled. This is standard Cloud KMS behavior.
  2. Re-encryption: Apigee X does not automatically re-encrypt existing data upon key rotation. Only new data or modified objects will utilize the primary (new) key version.

    “Cloud KMS does not automatically re-encrypt data… Existing data continues to be decrypted using the version that was active when it was written.” Cloud KMS Key Rotation


Verified Links & Sources: