GCP - CSEK vs CMEK
Key Differences Summarized
| Feature | CSEK (Customer-Supplied) | CMEK (Customer-Managed) |
|---|---|---|
| Key Location | Outside GCP (Managed by Customer) | Inside Google Cloud KMS (Managed by Customer) |
| Key Management | Customer's full external responsibility | Via Cloud KMS within GCP |
| GCP Stores Key? | No (only a hash for validation) | Yes (securely within Cloud KMS) |
| Provided To GCP | With every API request needing the key | Configured once per resource; used via KMS API |
| Service Support | Limited (mainly GCS objects, GCE disks) | Broad (many GCP services) |
| Control Level | Absolute (external) | Granular (via KMS policies, IAM) within GCP |
| Responsibility | Fully Customer | Shared (Customer manages key config, Google KMS infra) |
| Key Loss Impact | Permanent data loss | Data inaccessible (until key restored/re-enabled) |
| Integration | Operationally complex, per-request | Easier, integrated via resource config & KMS |
In short: Choose CSEK if you absolutely must keep your keys entirely outside Google Cloud and manage them yourself, accepting the operational complexity and limited service support. Choose CMEK if you need enhanced control, auditability, and centralized management of keys within GCP across a wide range of services, leveraging Cloud KMS.
CSEK (Customer-Supplied Encryption Keys)
- Concept: You create and manage your own encryption keys entirely outside of Google Cloud. When you interact with supported GCP services (like reading or writing an object in Cloud Storage or attaching a Compute Engine disk), you provide your AES-256 key along with each API request.
- Key Management: You are fully responsible for generating, securing, storing, rotating, and backing up these keys externally.
- GCP Interaction: Google Cloud uses the key you provide only for the duration of the operation to encrypt or decrypt the data. Google does not store your key persistently on its servers; it only stores a hash of the key to validate future requests.
- Control: You have absolute control over the key material because it never permanently resides within GCP.
- Responsibility: You bear the complete responsibility. If you lose your key, the data encrypted with it becomes permanently irrecoverable.
- Supported Services: Primarily Cloud Storage objects and Compute Engine persistent disks/local SSDs. It's not widely supported across all GCP services (e.g., not supported by BigQuery or Cloud SQL).
- Use Case: Typically used when strict regulatory or policy requirements demand that encryption keys are never stored by the cloud provider and remain entirely under the customer's external control. It adds significant operational overhead.
CMEK (Customer-Managed Encryption Keys)
- Concept: You use Google Cloud Key Management Service (Cloud KMS) to create, manage, and control your encryption keys within Google Cloud. You then configure supported GCP services to use specific keys stored in Cloud KMS to protect their data at rest.
- Key Management: Keys are managed centrally through Cloud KMS. You control the key's lifecycle (creation, rotation schedule, disabling, destruction) and access permissions (using IAM). Google manages the underlying secure infrastructure of Cloud KMS.
- GCP Interaction: Supported GCP services (like Cloud Storage, BigQuery, Compute Engine, Cloud SQL, etc.) are configured to use a specific KMS key. When these services need to encrypt or decrypt data, they make an internal call to the Cloud KMS API using the key you designated, leveraging GCP's IAM controls. The raw key material generally doesn't leave the KMS boundary.
- Control: You manage the keys' policies and lifecycle via Cloud KMS within GCP. You can grant/revoke permissions and disable/destroy keys to control access to the data encrypted by them.
- Responsibility: This is a shared responsibility model. You manage the key policies and lifecycle in KMS; Google secures and manages the KMS infrastructure.
- Supported Services: Has broad support across many GCP services (Cloud Storage, Compute Engine disks/snapshots/images, BigQuery, Cloud SQL, Pub/Sub, Bigtable, Spanner, Artifact Registry, Cloud Logging, etc. - see the official list for details).
- Use Case: Used when you need more control over encryption keys than Google's default encryption provides, require centralized key management within GCP, need auditable key usage logs (via Cloud Audit Logs), or must meet compliance requirements mandating customer-managed keys (but allowing them to be managed within the cloud provider's KMS).