Cloud KMS Encryption Key Management

Encryption strategies in Google Cloud determine who owns the keys that protect data at rest and how much control you have over those keys. Google-owned and Google-managed encryption protects all stored data automatically with no setup. Customer-Managed Encryption Keys (CMEK) (opens in a new tab) lets you own and control keys in Cloud Key Management Service (Cloud KMS) (opens in a new tab) for stronger control, visibility, and compliance.

1.1Google-Owned and Google-Managed Default Encryption

Google-owned and Google-managed default encryption is the automatic protection applied to all data stored in Google Cloud without any configuration. Data at rest is encrypted with the AES-256 standard using keys held in Keystore, Google Cloud's internal key management system, with cryptographic modules validated to FIPS 140-3 Level 1. Google automatically manages rotation and keeps a primary key version for encrypting new data encryption keys plus a limited number of older versions for decryption. You cannot view or manage these keys, review key usage logs, or isolate your data to a unique key, and data from multiple customers might share the same key encryption key.

1.2Customer-Managed Encryption Keys in Cloud KMS

Customer-Managed Encryption Keys (CMEK) are encryption keys that you own and manage in Cloud KMS to protect resources in supported services. A CMEK creates a cryptographic boundary around your data because each key can be unique to your workload, location, and compliance needs. Unlike default encryption, CMEK supports unlimited key versions for each key and gives you direct control over the full key lifecycle. Using Cloud KMS for CMEK adds cost based on active key versions and cryptographic operations, with no minimum purchase required.

You can use manually created CMEKs or keys created by Autokey to meet goals such as:

• Own your encryption keys and control their location, protection level, creation, and destruction.
• Control access to keys and control how keys are used through Identity and Access Management (IAM).
• Set or trigger the rotation period, change key status, and destroy or delete key versions, keys, and key rings.
• Generate key material in Cloud KMS or import material maintained outside Google Cloud.
• Enforce policy on where keys must be used and log administrative and data access to keys.
• Selectively delete protected data by destroying its key, a practice called crypto-shredding, for off-boarding or incident response.
• Meet current or future regulations that require customer ownership or control of keys.

1.3How CMEK Integrates with Google Cloud Data Services

A CMEK integration is server-side encryption in a supported Google Cloud service that uses your Cloud KMS key instead of Google's default encryption. After setup, encryption and decryption are handled by the service's service agent, so access to the resource feels the same as with default encryption and the end user needs no direct access to the key. The service agent depends on having the CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the CMEK to encrypt and decrypt data. If you revoke that role, or if you disable or destroy the key, the service can no longer decrypt its data, and some services can suffer permanent data loss if the key stays inaccessible too long.

Manually enabling CMEK follows an ordered workflow where the key and its permission must exist before the protected resource can use them:

1. Create or choose a key ring: Create a Cloud KMS key ring near the resources you will protect, in the same project or a separate project for separation of duties.
2. Create or import the key: Create or import a Cloud KMS key in that key ring to serve as the CMEK.
3. Grant the service agent access: Grant the service's service account the CryptoKey Encrypter/Decrypter IAM role on the CMEK.
4. Configure the resource to use the CMEK: Select the CMEK when creating the resource, such as a BigQuery table protected at rest by that key.

Cloud KMS Autokey simplifies this same integration by generating key rings and keys on demand during resource creation and automatically granting the service agent the required IAM roles. Keys created by Autokey follow best practices for location alignment, specificity, hardware protection level, rotation, and separation of duties, and they behave identically to manually created keys for monitoring, key usage tracking, and organization policy enforcement.

1.4Comparing Strategies and Enforcing Compliance

The choice between default encryption and CMEK comes down to simplicity versus control, auditability, and the ability to cut off access at the key layer.

Compliance with CMEK is enforced across the organization with policy constraints and monitoring. Organization administrators can require CMEK protection and limit which keys, protection levels, locations, and key-version destruction behaviors are allowed. Key usage tracking in Cloud KMS shows which resources, projects, and products depend on each key and whether each key is still in use, so key administrators can detect unexpected use and plan rotation or destruction safely.

Cloud Key Management Service (Cloud KMS) is Google Cloud's service for creating and managing the encryption keys that protect stored data. Encryption at rest in Google Cloud works by keeping the encrypted data and the key in different places, so a service such as Cloud Storage stores only encrypted data while Cloud KMS stores the customer-managed encryption key that can lock or unlock it. The service organizes this work in a hierarchy where a key ring holds one or more keys, and each key performs cryptographic operations through its key versions.

2.1Key Rings as Location Containers

A key ring in Cloud KMS is a container that groups keys together under one location and one Google Cloud project. The key ring sets the location boundary for every key it holds, so the key ring location must correspond to the location of the service that will use the keys. The project where the ring lives is called the key project, and that project must have Cloud KMS enabled before any ring or key can be created.

For example, when protecting Security Command Center (opens in a new tab) data, the Cloud KMS key ring location must match the Security Command Center location:

If data residency is not enabled for Security Command Center, the key ring is created in the us location. This location pairing shows why planning the key ring first matters, because the ring fixes where the keys can be used from.

2.2Keys as Named Resources

A key in Cloud KMS is the named resource created on a key ring that a cloud service uses to encrypt and decrypt its data. After configuration, the service sends an encrypt or decrypt request to Cloud KMS, Cloud KMS uses the key to perform the cryptographic operation, and the service never stores the key alongside the data it protects. This separation means the data stays encrypted at rest unless Cloud KMS allows the key to be used.

Keys also carry ownership and access controls that enforce security and compliance. The Cloud Security Command Center Service Agent, or the service agent for another integrated service, must have the required Identity and Access Management (IAM) role on the key or protected features will not work correctly. Organization policies can further require CMEK through constraints/gcp.restrictNonCmekServices and require that the key comes from an approved project through constraints/gcp.restrictCmekCryptoKeyProjects.

2.3Key Versions as Active Cryptographic Material

A key version in Cloud KMS is the actual cryptographic material inside a key that performs each encrypt or decrypt operation. A key can have more than one version over time, and concepts such as key states and key rotation control which version is available for new operations. Key Access Justifications (opens in a new tab) builds on this by generating a justification code for each cryptographic operation involving an enrolled key, so an administrator can view, approve, or deny access based on the reason provided.

Because versions change over time, logging and transparency controls track operations rather than only tracking the key name. Cloud KMS audit logs can record justification codes for key operations, and logging applies to keys with both hardware and software protection levels. Together, versions, states, rotation, and justification policies let an organization prove who used which key material, when, and why.

2.4How Key Rings, Keys, and Key Versions Protect Data Together

The three components work as an ordered chain from location to operation. First, an administrator installs and initializes the Google Cloud CLI, then builds the hierarchy in order:

1. Create the key project: Create a Google Cloud project with Cloud KMS enabled to own the rings and keys.
2. Create the key ring: Create the key ring in the location that corresponds to the service location.
3. Create the key: Create the Cloud KMS key on that key ring.
4. Grant service access: Grant the service agent the required IAM role on the key so the service can request encrypt and decrypt operations.

Once configured, data flows from the protected service to Cloud KMS for each cryptographic operation, and the key version inside the key performs the work. The protected service depends on the key, the key depends on its key ring for location and grouping, and Key Access Justifications plus organization policies sit above them as approval and enforcement boundaries.

Key Lifecycle Management in Cloud Key Management Service (Cloud KMS) is the process of creating, using, rotating, and disabling or destroying encryption keys to protect sensitive data. Each key contains one or more key versions, and the primary version is the version currently used for new encryption operations. Understanding how versions change state over time explains why new data can use a new key while old data still depends on an older version.

3.1Creating and Using Encryption Keys

Creating an encryption key establishes a new key with a primary version in the enabled state that services can use for encryption. Keys created for automation can use defaults such as HSM protection level, AES-256 GCM algorithm, and a one-year rotation period, and they are created in the same location as the resource they protect. A key is considered available only when the key version is enabled and the service account has encrypt and decrypt permissions on the key.

Using customer-managed encryption keys (CMEKs) (opens in a new tab) means Cloud Storage encrypts new objects with the primary version of the selected key. A bucket can have a default CMEK, and individual upload, copy, or rewrite operations can specify a key, but a single object can be encrypted by only one method at a time. If a bucket has a default CMEK and a request supplies a customer-supplied key, data flows from the request to Cloud Storage encrypted with the customer-supplied key instead of the bucket default.

3.2Rotating Keys for Ongoing Protection

Rotating a key in Cloud KMS creates a new key version through automatic or manual rotation and makes that new version the primary version. After rotation, Cloud Storage uses the new primary version for all new encryption with that key, including uploads to a bucket that uses the key as its default and uploads, copies, or rewrites that specifically name the key. Previous versions remain enabled so Cloud Storage can still decrypt existing objects that were encrypted with those versions.

Rotation alone does not re-encrypt existing data and does not disable or destroy older versions. Data encrypted with a previous version keeps the key version specified at the time of its creation until it is decrypted and re-encrypted with the new version. New backups use the latest primary version, while existing backups and persistent data continue to depend on the older version until a maintenance event or manual re-encryption moves them.

3.3Replacing Keys and Re-encrypting Data

Replacing a key moves protection from an old key to a whole new key, and re-encryption moves existing objects to the new key version or new key. Rotation never performs this move automatically, so replacement requires an ordered migration before the old key is disabled:

1. Replace the bucket default: Check which buckets use the old key as the default encryption key and replace it with the new key, so objects written to the bucket use the new key going forward.
2. Update ongoing operations: Inspect source code and configurations for requests that name the old key in uploads, copies, rewrites, or bucket settings, then update those instances to use the new key.
3. Re-encrypt existing objects: Identify all objects encrypted with the old key and use the Rewrite Object method to re-encrypt each object with the new key, using Storage batch operations for millions or billions of objects.
4. Disable the old key: Disable all versions of the old key only after re-encryption, then monitor client and service logs for operations that fail because a version became unavailable.

3.4Disabling or Destroying Key Versions

Disabling or destroying a key version removes the ability to decrypt any data encrypted with that specific version. When a version becomes unavailable, protected objects cannot be downloaded, copied, or rewritten, and attempts to do so result in an error. If the unavailable version is the primary version, the key cannot perform new encryption until a new primary version exists, so uploads, copies, or rewrites that name the key fail, and uploads to a bucket with that default key fail unless a different valid key is specified.

The choice between disabling and destroying controls whether access can be restored:

Destroying a version provides high-assurance destruction, also called crypto-shredding, which makes data permanently inaccessible even when the encrypted objects still exist. This approach is used for cases such as remediating a data spill, but it causes unrecoverable loss if any needed objects still depend on the destroyed version. Before disabling or destroying, identify every object encrypted with that version and re-encrypt it with a new key version, a new key, or Google-managed server-side keys.

Key Facts

• Google-owned and Google-managed default encryption protects data at rest automatically with AES-256, while Customer-Managed Encryption Keys (CMEK) in Cloud Key Management Service (Cloud KMS) give you ownership, location control, rotation control, and auditability.
• A key ring in Cloud KMS groups keys under one location and one project, a key is the named resource used by a service, and a key version holds the actual cryptographic material that performs encryption and decryption.
• A CMEK integration depends on the service agent having the CryptoKey Encrypter/Decrypter role on the key, and revoking access or disabling or destroying the key blocks decryption.
• Rotating a key makes a new version the primary version for new encryption without re-encrypting old data, while disabling a version reversibly blocks decryption and destroying a version permanently prevents decryption.