Customer-Managed Encryption Keys (CMEK) give organizations granular control over the cryptographic keys that protect data across Google Cloud services. When compliance requires that key material comes from outside Google Cloud, you can use key import to bring externally generated keys into Cloud KMS or use Cloud External Key Manager (Cloud EKM). Cloud KMS key import supports Bring Your Own Key (BYOK) scenarios for software or hardware protection levels, while Cloud EKM enables Hold Your Own Key (HYOK) architectures where the raw key material never leaves the external partner system. Imported key versions and external keys require manual rotation and active lifecycle monitoring because automatic rotation is not supported.
The key import process protects raw key material during transit from an on‑premises or external environment into Cloud KMS. First, Cloud KMS creates an import job that generates a public wrapping key. The client uses this wrapping key locally to encrypt the key material before uploading it to Google Cloud. When Cloud KMS receives the wrapped material, it unwraps the key inside the cryptographic boundary using the corresponding private wrapping key. For hardware‑protected keys, the private unwrapping key is restricted to Cloud HSM, so Google cannot access or unwrap the plaintext key material outside dedicated hardware. The essential steps are: generating an import job in Cloud KMS with a selected import method and wrapping algorithm, encrypting the target cryptographic key locally with the retrieved public wrapping key, and submitting the wrapped key material into a designated Cloud KMS key version.
Cloud EKM establishes real‑time communication between Google Cloud and supported external key management partners. This communication can happen over the public internet or through a private Virtual Private Cloud (VPC). Because the external key material is never cached or stored inside Google Cloud, the external key management system must remain continuously reachable for all cryptographic requests. If an external key becomes unreachable, Cloud KMS returns a precondition failure error that prevents access to CMEK‑protected workloads. Unresolved key unavailability can cause severe operational failures or permanent data loss in services such as Spanner if the keys remain unreachable for prolonged periods. Key operational practices include deploying EXTERNAL_VPC connections to reduce internet routing latency and enhance reliability, configuring Cloud Monitoring alerts and data access audit logs to detect reachability failures quickly, and maintaining support contracts with external partners to rapidly triage interoperability issues.
Authorization policies for imported and external keys must follow the principle of least privilege and separation of duties. Key lifecycle tasks are managed by administrators who hold the Cloud KMS Admin role, which cannot perform encrypt or decrypt operations. Google Cloud service resources interact with keys automatically through service agents that are assigned the Cloud KMS CryptoKey Encrypter/Decrypter role. Organization policy constraints such as constraints/gcp.restrictNonCmekServices and constraints/gcp.restrictCmekCryptoKeyProjects enforce centralized key management and require CMEK protection across cloud infrastructure, ensuring that imported keys are governed consistently.
Key revocation and destruction are critical operations that make sensitive data irretrievable when it is no longer needed or when security risks appear. These procedures apply to Customer‑Managed Encryption Keys (CMEK), External Key Manager (EKM) integrations, secrets in Secret Manager, HMAC keys, and certificates in Certificate Authority Service.
In Secret Manager, you can delete entire secrets or destroy specific versions using the delete_secret method or by scheduling versions for delayed destruction. When a secret version is destroyed, it becomes permanently inaccessible and cannot be recovered. The destruction process supports a configurable version destroy TTL (time‑to‑live), which lets organizations set delayed destruction windows that align with data retention policies and regulatory requirements such as GDPR or HIPAA. This ensures compliance while keeping the ability to remove sensitive credentials when necessary.
For CMEK and EKM integrations, revocation involves updating the key associations of the protected resources. To revoke access for a CMEK, you can update a secret to remove the CMEK key association using the gcloud secrets update command with the --regional-kms-key-name parameter set to the appropriate Cloud KMS key. For EKM scenarios, the external key manager controls key availability; revoking access at the external provider immediately makes encrypted data inaccessible. Organizations must plan revocation scenarios carefully, because once a CMEK or EKM key is revoked or destroyed, all data encrypted with that key becomes permanently unreadable.
HMAC keys in Cloud Storage require a specific two‑step workflow. First, you must deactivate the key by setting its state to INACTIVE. This prevents the key from being used for new requests, while existing operations may continue for up to three minutes during the state propagation period. After deactivation, you can safely delete the HMAC key, knowing that it cannot be recovered once removed. This two‑step process ensures that key revocation is intentional and prevents accidental loss of access to stored data.
The Certificate Authority Service provides certificate revocation capabilities that are essential for maintaining trust hierarchies. Certificates can be revoked using either their resource name or serial number, with an optional revocation reason such as key compromise, certificate termination, or privilege withdrawal. When a certificate is revoked, its serial number and reason appear in all future Certificate Revocation Lists (CRLs) until the certificate expires. Google Cloud generates out‑of‑band CRLs within 15 minutes of revocation, so relying parties can quickly identify compromised certificates. Organizations must maintain proper CRL retention policies to meet compliance requirements while ensuring timely revocation propagation.
When executing revocation and destruction, organizations must consider data retention policies, regulatory mandates, and audit requirements. Every revocation and destruction operation should be logged for compliance purposes, and organizations should document the business justification for key removal. Proper key management also includes implementing appropriate protection levels, using hardware security modules (HSM) when required by compliance frameworks, and ensuring that key rotation policies are in place before revocation so that continuous access to data can be maintained with newer keys.
Key rotation is the process of generating new cryptographic key versions to replace existing ones. It is a critical security practice that limits the impact of a potential key compromise. For Customer‑Managed Encryption Keys (CMEK) in Google Cloud, you can configure automated rotation schedules based on security best practices or compliance requirements such as PCI DSS. This involves setting a rotation period (for example, every 90 days) and optionally a next rotation time. Automated rotation creates new primary key versions on schedule, ensuring that newly encrypted data uses the latest key, while previously encrypted data remains accessible through older versions.
However, rotating a key does not automatically re‑encrypt existing data. This means dependent resources—such as databases, disks, or log buckets—continue to rely on the original key versions for decrypting older data. Managing the transition between key versions is essential for maintaining data accessibility. You must plan for the coexistence of multiple key versions and understand that destroying an old version could render associated data unrecoverable. Services like Cloud SQL, Compute Engine, and Cloud Logging each have specific behaviors and limitations during rotation that must be evaluated.
To implement automated rotation, you use Cloud Key Management Service (Cloud KMS) to define the schedule for a CMEK key. You can also perform manual rotation immediately if a key is suspected to be compromised. After rotation, it is crucial to monitor key usage and the impact on dependent resources. Some services may require explicit re‑encryption operations to migrate data to the new key version. Proper Identity and Access Management (IAM) permissions must be maintained so that service accounts (such as those for Cloud SQL or Logging) retain the cloudkms.cryptoKeyEncrypterDecrypter role on the new key versions.
For keys managed externally through Cloud External Key Manager (EKM), rotation involves additional steps. You must first rotate the key material within your external key management system, then update the key path in the Cloud KMS key resource. This process requires careful coordination to ensure high availability of the external service, because its unavailability could prevent cryptographic operations and disrupt access to encrypted data in Google Cloud. Architectures for EKM should include redundancy and low‑latency connectivity to avoid such failures.
Professional Cloud Security Engineer
Gauge your current knowledge
Gauge your current knowledge
StudyCerts
StudyCerts