Cloud KMS is a managed service for creating and using cryptographic keys, without ever needing to handle the raw key yourself.

Cloud KMS lets you create keys, control who may use them, and ask the service to perform cryptographic operations on your behalf, such as encrypting a piece of data, decrypting it again, signing a message or checking a signature. The most valuable property is that the secret key material can stay inside the service. Your application sends data to Cloud KMS and receives a result, and the key itself never has to appear in your code, your configuration files or your laptop.

Cloud KMS also connects to many other Google Cloud services. When a storage bucket, a database or a disk is protected with a key that you manage in Cloud KMS, the arrangement is called customer-managed encryption keys, shortened to CMEK. This gives you control: you decide who can use the key, how often it changes, and you can disable it to make the protected data unreadable.

What Cloud KMS is not

Cloud KMS is not a place to store ordinary passwords or application secrets such as database credentials. Google Cloud has a separate service for secrets. Cloud KMS manages cryptographic keys and performs cryptographic operations. It is also not a replacement for good access control, because a key that anyone can use protects nothing.

Encryption is only as strong as the care given to its keys.

Modern encryption algorithms are extremely strong. Nobody breaks them by clever mathematics. Attackers instead look for the keys, because stealing a key is far easier than defeating the algorithm. So the real security question is never just “is the data encrypted?” It is “where are the keys, who can use them, how are they changed, and could we notice misuse?”

Learn these words once and the documentation becomes much easier to read.

Two families of cryptography do different jobs, and Cloud KMS supports both.

Symmetric encryption uses one secret key for both locking and unlocking. It is fast, which makes it the right tool for protecting large amounts of data such as files and database contents. The trade-off is that anyone who needs to unlock the data must hold the same secret, so the secret must be shared with great care.

Asymmetric cryptography uses a pair of mathematically linked keys. The public key can be shared with anyone. The private key is kept secret. Data locked with the public key can be unlocked only by the private key, and a signature made with the private key can be checked by anyone using the public key. It is slower, so it is used for small things like exchanging secrets and proving identity.

Almost all cloud encryption uses a two-layer design called envelope encryption.

Sending large amounts of data to a key service for every operation would be slow and costly. Instead, data is encrypted with a data encryption key, called a DEK, which is generated locally and is used to scramble the data quickly. The DEK itself is then encrypted with a stronger, central key, called a key encryption key, or KEK, which lives in Cloud KMS. The encrypted DEK is stored next to the encrypted data. To read the data, the system asks Cloud KMS to unwrap the DEK, then uses the DEK to unlock the data.

sequenceDiagram
  participant App as Application
  participant KMS as Cloud KMS
  participant Store as Storage
  App->>App: Create a fresh data key
  App->>App: Encrypt data with the data key
  App->>KMS: Wrap the data key with the master key
  KMS-->>App: Wrapped data key
  App->>Store: Save encrypted data and wrapped data key
  Note over App,Store: Later, to read the data
  App->>Store: Fetch encrypted data and wrapped key
  App->>KMS: Unwrap the data key
  KMS-->>App: Plain data key
  App->>App: Decrypt data, then discard data key
        

Why this design is so popular

Google Cloud offers a spectrum from fully managed by Google to fully controlled by you.

By default, Google Cloud encrypts customer data at rest automatically, using keys that Google manages. You do not need to do anything. Some organizations want more control, for compliance or for their own security policy, and Cloud KMS provides that control in steps.

Moving to a higher level of control is a business decision. More control brings more responsibility. If you mismanage a key you control, your data may become unavailable, and no one at Google can rescue it.

Cloud KMS organizes keys in three levels inside a project.

flowchart TD
  P["Project"] --> KR1["Key ring: payments, location europe-west1"]
  P --> KR2["Key ring: logs, location us-central1"]
  KR1 --> K1["Key: card-data (symmetric encryption)"]
  KR1 --> K2["Key: invoice-signing (asymmetric signing)"]
  K1 --> V1["Version 1"]
  K1 --> V2["Version 2 (primary)"]
  K2 --> V3["Version 1"]
        

Two facts matter for planning. First, resources cannot be moved to a different location after creation, so choose the location carefully at the start. Second, key rings and keys cannot be renamed, and the names of deleted keys cannot be reused, so choose names that will still make sense years later.

Where a key lives affects speed, compliance and availability.

Every key ring is created in a specific location, which may be a single region, a multi-region or the global location. The location of a key determines where its key material is stored and processed. For the best results, keep the key in the same location as the data it protects: a service in one region should use a key in that same region, because this reduces delay and avoids confusing dependency across regions.

When you create a key, you decide once what it is for, and this cannot be changed later.

Every key has a purpose, which defines the operations allowed with it, such as symmetric encrypt and decrypt, asymmetric signing, asymmetric decryption, or message authentication. The purpose is set at creation and cannot be changed. Every version of the key shares the same purpose. The type, symmetric or asymmetric, is part of the purpose.

Because the purpose is permanent, plan your keys by job. One key for encrypting a database, one for signing releases and one for protecting backups, for example, each with its own access rules. Mixing jobs on a single key couples unrelated systems and makes access control clumsy.

Each key version moves through a small set of states, and knowing them prevents disasters.

stateDiagram-v2
  [*] --> Enabled
  Enabled --> Disabled: disable
  Disabled --> Enabled: re-enable
  Enabled --> ScheduledForDestruction: schedule destroy
  Disabled --> ScheduledForDestruction: schedule destroy
  ScheduledForDestruction --> Disabled: restore before deadline
  ScheduledForDestruction --> Destroyed: delay period ends
  Destroyed --> [*]
        

Google’s documentation notes that versions in any state other than destroyed are billed, which is a reason to destroy versions you truly no longer need, after the safety steps in the destruction chapter. Disabling or destroying a whole key disables or destroys all of its versions at once.

When you ask a key to encrypt, someone must decide which version does the work.

Symmetric encryption keys have a primary version. When you encrypt without naming a version, Cloud KMS uses the primary. The result carries information about which version was used, so decryption automatically picks the right one, as long as that version is still enabled. Asymmetric keys have no primary version, so you always specify the version, since a public key and signature belong to a particular version.

Rotation limits how much data any single key version protects and how long a leak could matter.

Rotating a key means creating a new version and making it the primary. Older versions remain available to decrypt data they protected. Google’s documentation points out that rotation by itself is a free administrative operation, while re-encrypting existing data with the new version counts as ordinary cryptographic operations that are billed. Many organizations schedule automatic rotation for symmetric keys at a regular interval, such as every few months, and rotate immediately if a compromise is suspected.

Rotation versus re-encryption

A common misunderstanding is that rotation protects data already stored. It does not by itself. Data encrypted with version 1 stays protected by version 1 until someone re-encrypts it with a newer version. If you truly need old data protected by a new key, for example after a suspected leak, you must run a re-encryption job. For many services using CMEK, the service handles key wrapping, and the exact behavior on rotation depends on the service, so read its documentation.

The protection level tells you where the key lives and how strongly it is guarded.

flowchart TD
  Q["Do you have a specific requirement?"] -->|"No special rules"| S["Software keys"]
  Q -->|"Need certified hardware"| H["Cloud HSM"]
  Q -->|"Need dedicated isolated hardware"| T["Single-tenant HSM"]
  Q -->|"Google must not hold key material"| E["External key manager"]
        

All levels share common features: you can use them with CMEK-integrated services (although some services do not support external keys), control them with IAM, enable or disable individual versions and see operations in audit logs. The next three chapters look at each level in turn.

The default and cheapest option, suitable for most workloads without special regulatory requirements.

With software protection, cryptographic operations run in software inside Google’s key management service, using Google’s cryptographic module. Keys can be generated by Google or imported. Software keys are the cheapest, and for the great majority of businesses they provide excellent protection, since the keys are never exposed outside the service and every use is controlled by access rules and recorded in audit logs.

Google’s documentation describes software keys as a good fit for workloads without specific regulatory requirements for a higher validation level. If a regulator or customer contract names a specific hardware standard, move up a level.

Hardware security modules keep keys inside tamper-resistant devices.

A hardware security module is a specialized physical device built so that keys inside cannot be read out, even by someone with physical access. With Cloud HSM, Google operates these devices, and your keys live and are used inside them. According to Google’s documentation, the multi-tenant HSM offering uses hardware validated to FIPS 140-2 Level 3. Each key has an attestation statement and certificate chains that can be used to verify the key and hardware properties. You use Cloud HSM through the same Cloud KMS interfaces, with no special HSM-specific code, simply by choosing the HSM protection level when creating a key.

Two forms

For the strictest demands, the key never has to enter Google Cloud at all.

Cloud External Key Manager, or Cloud EKM, lets you keep keys in an external key management system run by you or by a supported partner. Google Cloud stores extra cryptographic material and a path to your external key, but according to the documentation, when you use Cloud EKM keys, Google Cloud cannot access your key material. When a service needs to unwrap a data key, the request travels to your external system, which decides whether to allow it.

Two network paths exist: over the internet, and over a private network connection called a VPC. The documentation notes that the internet path carries availability risk and recommends the VPC path or Cloud HSM for better availability. If your external system is unreachable, the data it protects can become temporarily unreadable.

Sometimes the key must come from outside, and Cloud KMS supports importing it.

Normally Cloud KMS generates key material itself, which is the safest approach because the material never exists anywhere else. In certain cases, for example when migrating from another system or meeting a rule that requires you to generate keys in your own process, you can import key material into software or HSM keys. Google’s documentation describes the generated or imported origin for these levels. Import uses a wrapping process so the key is protected while traveling to Cloud KMS.

Exact steps and supported algorithms evolve, so follow the current import documentation. Whenever possible, prefer keys generated inside Cloud KMS.

The most common way to use Cloud KMS is to point another Google Cloud service at a key you control.

Many Google Cloud services, including storage, databases, data warehouses, messaging and disks, can be configured to protect their data with a customer-managed key from Cloud KMS. Once configured, the service uses envelope encryption in the background. It generates data keys, wraps them with your key, stores the wrapped result, and calls Cloud KMS whenever it needs to unwrap. You do not change your application. You only decide which key protects which resource.

The permissions work through service agents. Each service has a special identity, managed by Google, that acts on your project’s behalf. To let a service use your key, you grant that service’s identity a narrow role that allows encrypting and decrypting with the key and nothing more. If you later remove that permission, or disable the key, the service can no longer unwrap the data keys, and the protected data becomes unreadable until access is restored.

What changes when you choose CMEK

Autokey automates the busywork of creating keys for the services that need them.

Setting up CMEK by hand means creating key rings, creating keys, granting service permissions and remembering conventions. Across hundreds of resources, mistakes and inconsistencies are likely. Autokey is a Cloud KMS feature that creates keys on demand as developers create resources, following the structure and rules the security team defined. Developers get protected resources without waiting for a ticket, and security teams keep consistent naming, locations and protection levels.

The pricing page also notes a small free allowance connected to Autokey-created keys, covering a limited number of key versions and operations each month, aggregated across projects for a billing account. Confirm the current allowance and conditions before relying on it.

Who may manage a key and who may use it are two different questions, and they should have different answers.

Cloud KMS uses Identity and Access Management to control access. A key administrator can create, rotate, disable and destroy keys, but should not necessarily be able to use the key to read data. A key user, which may be a service or a person, can encrypt and decrypt, but should not be able to change or destroy the key. Keeping these roles apart is called separation of duties, and it is one of the best protections against both mistakes and abuse.

Think about emergencies too. If a key must be disabled at once because of a suspected breach, who is allowed to do it, and how quickly can they be reached? A good design names an on-call group with that power, records every use of it, and rehearses the procedure, so that a real emergency is handled calmly instead of through frantic permission requests.

Practical rules

A key you cannot watch is a key you cannot trust.

Google Cloud’s audit logs record administrative actions on Cloud KMS, such as creating, disabling or destroying keys. Data access logs can record each use of a key for encryption or decryption, when enabled, which may produce a large volume of entries for busy services. Google’s documentation confirms that key operations appear in audit logs. Together, these logs answer who used which key, when, and from where.

A useful habit is to decide, in advance, what normal looks like for each important key. A payments encryption key might be used thousands of times per hour by two known service identities during business hours. If the logs suddenly show a different identity, a different country or a burst at three in the morning, the difference stands out immediately. Without a picture of normal, every pattern looks plausible, and real attacks hide in the noise.

Logs also support compliance. Auditors often ask for proof that only approved people changed keys, that rotations happened on schedule and that destroyed keys were approved. If your logs and approval records are organized, such questions take minutes. If they are scattered, the same questions take weeks and shake confidence in the whole program.

Events worth an alert

Destruction is the only truly irreversible action in the service, so it deserves a ritual.

When a key version is destroyed, its key material is permanently deleted. Any data that depends on that version alone can never be decrypted again, by you, by Google or by anyone. This is exactly what you want when you intend to erase data by destroying its key, a technique sometimes called crypto-shredding. It is a disaster if done by mistake.

Cloud KMS reduces the risk through a scheduled destruction delay. When you request destruction, the version enters a scheduled for destruction state and stays recoverable until the delay ends. The length of this delay is configurable when the key is created, and the documentation I reviewed did not state a default, so check the current default and choose a delay that gives your team time to notice mistakes. A longer delay is safer, though versions in this state are still billed.

Encryption keeps secrets. Signatures prove who made something and that it was not changed.

An asymmetric signing key lets you create a digital signature over a document, software package or token. The private key stays inside Cloud KMS, where only authorized identities can request signatures. Anyone can verify the signature using the public key, which can be downloaded and shared freely. If a single character of the document changes afterward, verification fails.

Message authentication codes, often shortened to MACs, are a related tool that uses a shared secret. Both the sender and the checker hold the same key, and the code proves that the message came from someone with the key and was not altered. Cloud KMS supports key purposes for both patterns.

Because asymmetric keys have no primary version, signing and verification always reference an explicit version. Keep old public keys available as long as signatures made with them still need to be checked, even after you stop signing with those versions.

Good key design balances isolation, simplicity and cost.

A key layout decides how many keys you have, how they are grouped and who can use each. At one extreme, a single key protects everything, which is cheap and simple but disastrous if the key is lost or misused. At the other extreme, a different key protects every object, which provides isolation but may be costly and complex. Most organizations choose a middle path.

Naming and organizing

A typical, sensible arrangement that many companies can adapt.

In this arrangement, a dedicated key project holds all production keys, with key rings per application and per location. A security team administers the keys, application teams cannot see or change them, and each application’s service account can use only its own key. Audit logs are exported to a protected logging project. Storage and databases use CMEK, and a signing key protects release pipelines.

flowchart LR
  subgraph KP["Key project (security team only)"]
    KR["Key ring per app and location"]
    K1["Encryption key"]
    K2["Signing key"]
    KR --> K1
    KR --> K2
  end
  subgraph AP["Application project"]
    DB["Database with CMEK"]
    BK["Storage bucket with CMEK"]
    CI["Build pipeline"]
  end
  DB -->|"service agent wraps and unwraps"| K1
  BK -->|"service agent wraps and unwraps"| K1
  CI -->|"requests signatures"| K2
  KP --> LG["Audit logs to protected logging project"]
  AL["Alerts on disable, destroy, permission change"] --- LG
        

Why this works

Cloud KMS pricing has two main parts: how many key versions you keep, and how many operations you perform.

On the pricing page I reviewed, an active key version is billed for as long as it exists in any state other than destroyed. That means enabled, disabled and scheduled for destruction all cost money, while destroyed versions are free. Prices rise with the protection level. Illustrative monthly equivalents shown there were roughly six cents for a software key version, about one dollar for a hardware-protected symmetric or RSA 2048 key version, and about three dollars for an external key version, with some hardware key types priced higher in a tiered table. Cryptographic operations were listed at about three cents per ten thousand, with some hardware operations at a higher rate, and administrative operations such as rotation were free. Single-tenant HSM instances have a separate and much larger hourly charge. Prices change, and some details on the page were unclear, so always confirm on the official page and SKU list.

Ways to keep the bill sensible

Note also that all charges go to the project that owns the key, even when the key protects resources in other projects. If you want cost visibility per application team, consider labels and billing reports, and remember this when placing keys in a central key project.

Stories show how these ideas appear in daily life.

The right answer depends on your rules and risks, not on what sounds most secure.

Moving up this table adds control and cost together, and often adds operational responsibility too. Many teams start at CMEK with software keys for sensitive data, and upgrade specific keys when a clear requirement appears. Because the protection level is chosen per key, one organization can use several levels at once, matching each data set to its needs.

Architects write down significant choices so later teams understand the reasons.

The cheapest education is learning from other teams’ mistakes.

Five classic traps in detail

Start with the simplest cause and work toward the hardest.

A calm method

A short list to review before every launch.

Quick answers to the questions beginners ask most often.

Everything in this guide on one short page.

Cloud KMS lets you create and use cryptographic keys without ever exposing them. Keys are organized into key rings, keys and versions in a chosen location. Envelope encryption lets services protect large data cheaply while you keep central control of a master key. You choose a protection level of software, hardware or external according to your rules, control access with separated roles, rotate on a schedule, watch audit logs and destroy keys only with great care. Handled well, keys become a source of confidence. Handled carelessly, they become a source of outages and exposure.