Cloud KMS is a managed service for creating and controlling cryptographic keys, so that you never have to hide keys inside your own code or servers.

The problem it solves

Encryption is the process of scrambling readable information, called plaintext, into unreadable information, called ciphertext, using a secret value known as a key. Only someone holding the right key can turn the ciphertext back into plaintext. The math behind modern encryption is public and trusted; the real security of any system therefore depends almost entirely on how well the keys are protected.

Before managed key services, teams stored keys in configuration files, environment settings, or even source code. A single leaked file could expose every secret. Keys were rarely changed because changing them was painful, and nobody could say with confidence who had used a key last month. Cloud KMS removes these weaknesses by giving keys a proper home with strict rules around them.

What the service actually does

Cloud KMS lets you create keys, store them securely, use them to encrypt, decrypt, sign and verify information, rotate them on a schedule, disable them, and eventually destroy them. Crucially, for most key types the raw key material never leaves the service in readable form. Instead of fetching a key and doing the work yourself, you send data to the service and ask it to perform the operation. The key stays inside the vault, and only the result comes back.

It is a managed service, so there are no servers to run, no hardware to buy for the standard options, and no software to patch. Google operates the infrastructure, while you decide who may use which key and for what purpose.

Cloud KMS works with several neighbours, and confusing them is the most common beginner mistake.

Key Management Service versus Secret Manager

This is the question beginners ask most. A secret, such as a database password, is a value your application must actually read in order to log in somewhere. Secret Manager stores that value and hands it to authorised callers. A cryptographic key, on the other hand, is not usually read at all. You ask the service to encrypt or sign something with it, and the key never leaves. Many solutions use both: Secret Manager stores a password, and a key from Cloud KMS protects the stored data or controls how the secret store itself is encrypted.

flowchart LR
  A["Your application"] -->|"Asks to encrypt or sign"| K["Cloud KMS"]
  K -->|"Returns result only"| A
  K --> I["IAM permission check"]
  K --> L["Audit logs"]
  S["Google Cloud services"] -->|"Use your key for data at rest"| K
  K -.-> H["Cloud HSM option"]
  K -.-> E["External key manager option"]
        

A small set of words unlocks the whole service.

Five levels, each with a clear job, form the map of everything in Cloud KMS.

Every object in Cloud KMS lives inside a strict hierarchy, and understanding it removes most confusion about names, permissions and mistakes that cannot be undone.

flowchart TD
  P["Project"] --> LOC["Location such as a region"]
  LOC --> KR1["Key ring: payments"]
  LOC --> KR2["Key ring: analytics"]
  KR1 --> K1["Key: card-data"]
  KR1 --> K2["Key: token-signing"]
  K1 --> V1["Version 1 - disabled"]
  K1 --> V2["Version 2 - enabled"]
  K1 --> V3["Version 3 - primary"]
        

Why location matters so much

A key ring is created in one location, and that location cannot be changed later. When a Google Cloud service uses your key for data protection, the service location and the key location normally need to be compatible, usually the same region or an appropriate multi-region or global option. A mismatch is one of the most common reasons a setup fails on the first try. Plan locations before creating anything, and match them to where your data lives and to any rules about where data may be processed.

Organising key rings sensibly

Most teams group keys by application, environment or data sensitivity, for example one key ring for payment data in production and another for analytics in testing. Because access can be granted at key ring level and flows down to the keys inside, the grouping you choose directly shapes who can do what. Do not put keys for very different teams into one key ring just for convenience, or access rules will become awkward later.

The purpose chosen at creation decides what a key can ever do.

When you create a key you choose its purpose, and this cannot be changed afterwards. Each purpose supports certain operations and certain algorithms, so the choice matters.

Symmetric keys: the everyday workhorse

Symmetric keys use one secret for both directions. They are fast and are the standard choice for protecting data at rest and for wrapping other keys. In Cloud KMS, symmetric keys support automatic rotation and a primary version concept, and the service records which version protected each piece of ciphertext so that decryption picks the right one automatically.

Asymmetric keys: a public face and a private secret

Asymmetric keys come in pairs. The public half can be shared freely, and the private half stays inside Cloud KMS. For encryption, anyone can use the public half to lock data that only the private half can unlock. For signing, only the private half can create a signature, while anyone with the public half can check it. Cloud KMS lets you download the public half, but the private half is never exported.

Message authentication codes

A message authentication code, often called an HMAC, is a short tag computed from a message and a secret. Anyone with the same secret can recompute the tag and confirm that the message is unchanged and came from someone who knows the secret. It is useful for protecting messages between your own services, such as webhook calls or cookies, without needing a full signature system.

The protection level decides where your key material physically lives and who can ever touch it.

Every key is created with a protection level. It is chosen at creation time and describes where the key material is stored and used. There are three families, and each trades cost and control in a different way.

Software protection

Software-protected keys are processed in Google-managed software environments and are suitable for the large majority of use cases. They are generally validated to a lower assurance level than hardware modules, but they are strong, well-audited and economical. If no rule forces you to choose otherwise, this is the sensible starting point.

Hardware protection

Cloud HSM keys are generated and used inside hardware security modules, devices designed so that keys cannot be extracted even by someone with physical access to them. Google documents that these modules are validated at a high government-recognised assurance level, and you should check the current documentation for the exact standard and level. Choose this when a regulation, a customer contract or your own risk policy requires hardware protection.

External key management

With external key management, the key never enters Google Cloud. A supported partner system holds it, and Google services send small requests to unwrap data keys when they need them. The benefit is control: if you cut the connection or disable the key at the partner, Google can no longer decrypt your data. The price is dependency: if the external system is slow or unavailable, your services that rely on the key may fail too.

flowchart TD
  Q1{"Do rules require keys outside the cloud provider?"}
  Q1 -->|Yes| EKM["Choose external key management"]
  Q1 -->|No| Q2{"Do rules require hardware protection?"}
  Q2 -->|Yes| HSM["Choose Cloud HSM"]
  Q2 -->|No| SW["Choose software protection"]
        

Almost every real system uses two layers of keys. Understanding why is the single most useful idea in this guide.

The problem with encrypting everything directly

You could, in theory, send all your data to Cloud KMS and ask it to encrypt every byte. But the service has limits on how much data it accepts in one request, every round trip adds delay, and sending huge files across a network just to encrypt them is wasteful. At the same time, you do not want a powerful master key floating around in application memory. Envelope encryption solves both problems.

How envelope encryption works

The idea has two kinds of keys. A data encryption key, often shortened to DEK, is a fresh key generated locally and used to encrypt the actual data. A key encryption key, or KEK, lives in Cloud KMS and is used only to wrap, meaning encrypt, the DEK. The wrapped DEK is stored right next to the encrypted data. To read the data later, the system asks Cloud KMS to unwrap the DEK, then uses it locally to decrypt.

sequenceDiagram
  participant App as Application or service
  participant KMS as Cloud KMS
  participant Store as Storage
  App->>App: Create data key and encrypt data
  App->>KMS: Wrap data key with master key
  KMS-->>App: Wrapped data key
  App->>Store: Save encrypted data and wrapped key
  Note over App,Store: Time passes
  App->>Store: Read encrypted data and wrapped key
  App->>KMS: Unwrap data key
  KMS-->>App: Plain data key
  App->>App: Decrypt data then discard key
        

Why this design is so powerful

A key version is born, works, rests, and eventually dies, and each stage has a name.

Every key version has a state, and the state decides what you can do with it. Knowing the states prevents the most expensive type of mistake, which is making data unreadable by accident.

stateDiagram-v2
  [*] --> PendingGeneration
  PendingGeneration --> Enabled: Ready
  Enabled --> Disabled: Switch off
  Disabled --> Enabled: Switch on
  Enabled --> ScheduledForDestruction: Request destroy
  Disabled --> ScheduledForDestruction: Request destroy
  ScheduledForDestruction --> Disabled: Restore during wait
  ScheduledForDestruction --> Destroyed: Wait period ends
  Destroyed --> [*]
        

The safety waiting period

When you destroy a key version, it does not vanish immediately. It first enters a waiting period during which it is unusable but recoverable. The default waiting period is documented as thirty days, and a different value can be chosen when the key is created, within limits that are described in the current documentation. This pause exists because mistakes happen, and a short grace period has saved many teams from an irreversible error.

Rotation limits how much data any single secret ever protects.

What rotation means

Rotating a key means creating a new version and making it the one used for new work. The older versions stay in place so that data encrypted earlier can still be decrypted. Over time a key accumulates versions, and the newest one handles all fresh encryption. Rotation is therefore like changing the locks on a building for new tenants while keeping the old keys safely stored for anyone who still needs to retrieve old belongings.

Why rotate at all

Automatic and manual rotation

For symmetric encryption keys, Cloud KMS can rotate automatically on a schedule that you choose, and the documentation states a minimum interval. Each time the schedule fires, a new version is created and promoted to primary. You can also rotate manually at any time, for example after a security incident or when a team member with high access leaves. For asymmetric keys, rotation is a manual job, because the public half must be shared with others, who need to be told about the new one.

The same power that protects data can also make it vanish, so handle the off-switch with respect.

Disable: the gentle brake

Disabling a key version stops all use of it right away while keeping it recoverable. Disabling is the safest way to answer the question “what would break if this key were gone?”. You switch it off during a quiet period, watch for failures, and switch it back on at once if something important breaks. This practice is sometimes called a scream test, because anything that depended on the key will complain loudly.

Destroy: the permanent step

Destroying a version schedules its removal after the waiting period. When the timer ends, the key material is erased and the data it protected becomes unreadable forever. Teams use this deliberately for retired keys that no longer protect anything, and they use it with great care.

Crypto-shredding

Sometimes deleting data itself is hard, for example when copies exist in many backups. A technique called crypto-shredding solves this: if all the data was encrypted with one key, destroying the key makes every copy permanently unreadable at once. This is powerful for meeting deletion promises, such as removing a customer’s data on request, because the ciphertext that remains is just meaningless noise.

flowchart TD
  A["Plan to retire a key"] --> B["List what depends on it"]
  B --> C["Disable the key version"]
  C --> D{"Did anything break?"}
  D -->|Yes| E["Enable again and fix the dependency"]
  D -->|No| F["Wait through an agreed observation period"]
  F --> G["Schedule destruction"]
  G --> H["Waiting period passes"]
  H --> I["Key material destroyed"]
        

This is where most teams meet Cloud KMS: asking other services to protect your data with your key.

Three levels of control

Google Cloud offers several answers to the question “who controls the key that protects my data at rest?”. The choice is a ladder: more control brings more responsibility.

How a service uses your key

Many Google Cloud services, including storage, databases, analytics, disks and container platforms, can be configured to use a key from Cloud KMS. The service does not use your personal identity. Instead, each service has its own special account, called a service agent, which acts on its behalf. You grant that service agent permission to use your key for encryption and decryption. From then on the service wraps and unwraps its internal data keys using your master key.

sequenceDiagram
  participant You as Security admin
  participant KMS as Cloud KMS
  participant SA as Service agent
  participant Svc as Storage or database service
  You->>KMS: Create key and grant service agent access
  You->>Svc: Create resource that uses the key
  Svc->>SA: Need to protect data
  SA->>KMS: Wrap internal data key
  KMS-->>SA: Wrapped data key
  Svc->>Svc: Store data encrypted
  Note over You,KMS: You can later disable the key to block access
        

The strongest feature: revocation

The key advantage of CMEK is that you can pull the plug. If you disable the key or remove the permission from the service agent, the service can no longer unwrap its data keys, and your data becomes unreadable through that service. This gives you a lever for emergency response and for contractual promises, but it also means a mistake in key management can take an application offline.

Automated key setup

Setting up keys by hand for every new bucket or database becomes tedious in large organisations. Google offers an automation feature for this, often called Autokey, where the right keys and key rings are created on demand when a team creates a protected resource, following the organisation’s central rules. This reduces mistakes and makes protection the easy default. Check the current documentation for supported services and prerequisites.

The people who manage keys should not be the same people who can use them.

Cloud KMS is controlled through Identity and Access Management. Permissions are bundled into roles, and roles can be granted on a project, a key ring or a single key. The best designs use a principle called separation of duties, meaning that no single person or account holds all the powers needed to do harm.

Where to grant roles

Granting a role at a single key gives the narrowest access. Granting at the key ring covers every key in it. Granting at the project covers every key in every key ring of that project. The rule of thumb is to grant at the lowest level that works. Broad grants at project or folder level are convenient today and dangerous tomorrow, when new keys appear automatically under them.

flowchart LR
  ADM["Key administrators"] -->|"Manage lifecycle only"| KEY["Key"]
  APP["Application identity"] -->|"Encrypt and decrypt only"| KEY
  AUD["Auditors"] -->|"View metadata and logs"| KEY
  ADM -. "Cannot use key" .-> DATA["Protected data"]
  APP --> DATA
        

Principles to follow

A key you cannot account for is a key you cannot trust.

Two kinds of audit records

Cloud Audit Logs record what happens to your keys. Administrative actions, such as creating a key, changing permissions, rotating, disabling or scheduling destruction, are recorded by default and cannot be switched off. Data access records, such as every encrypt and decrypt request, may need to be turned on explicitly, and they can produce a large volume of entries on busy systems. Decide deliberately which keys deserve full data access logging, usually the most sensitive ones.

Alerts worth having

Seeing what depends on a key

Cloud KMS provides views that help answer the question “which resources are protected by this key?”. Key usage tracking and inventory features show the Google Cloud resources that use a key, which is invaluable before any disable or destroy decision. These views depend on supported services, so confirm the current coverage in the documentation, and do not treat an empty result as proof that nothing depends on the key.

flowchart LR
  K["Cloud KMS activity"] --> AL["Cloud Audit Logs"]
  AL --> LB["Log-based metrics and alerts"]
  AL --> SINK["Export to long-term storage or analytics"]
  LB --> ON["On-call security engineer"]
  SINK --> AU["Auditors and investigations"]
  K --> KU["Key usage and inventory views"]
  KU --> PL["Safe change planning"]
        

Sometimes you already own key material, or the rules say it must stay outside the cloud.

Bringing your own key material

Cloud KMS lets you import key material that you generated elsewhere. The import is done through a protected process: you create an import job, which provides a special wrapping key, you wrap your key material with it, and the service unwraps and stores it inside the protected boundary. This keeps your key from travelling in readable form. People choose this when they need to prove where a key came from, or to keep a copy under their own custody.

External keys in more detail

With external key management, a supported partner system holds the key. Your Google Cloud service sends a small request to unwrap its data key through an agreed path, and the partner system decides whether to allow it. Some arrangements add a justification step, in which every request carries a stated reason that your policy can approve or reject. This gives very strong control but has a real cost in complexity.

Keys are on the critical path of your data, so their reliability becomes your reliability.

Location choices

Choose the location that matches the service using the key. A database in one region usually wants a key in that region. A service that spans a continent might use a matching multi-region. Compatibility rules are service specific, so read the service documentation before creating keys.

Think of key service as a dependency

Every time your application needs to unwrap a data key, it depends on Cloud KMS being reachable and responsive. For most workloads this is a minor point, but busy systems should treat the key service as a dependency with its own latency and limits. Techniques such as caching an unwrapped data key in memory for a short period, never writing it to disk, can reduce load and delay while keeping the master key safe.

Quotas and limits

Cloud KMS has request quotas that limit how many operations can be performed per minute, with different limits for different operation types and protection levels. Hardware-protected keys often have tighter limits than software keys. Heavy workloads that encrypt many small items directly with Cloud KMS can hit these limits, which is another reason envelope encryption with local data keys is preferred. Review current quotas, request increases ahead of launches, and design retries with gradual back-off for temporary errors.

Costs are modest for most teams, but they are easy to multiply by accident.

Cloud KMS pricing is built from a few simple ideas. Always read the current pricing page for exact figures, because they change and differ by protection level and location.

How versions add up

Because every rotation creates a new version, and old versions stay until you destroy them, the number of versions grows over time. For software keys the cost per version is small, but for hardware-protected keys it is more meaningful. A tidy retirement process, disabling and then destroying versions that no data depends on, keeps both risk and cost under control.

A calm, ordered path from an empty project to a protected resource.

Setting up Cloud KMS is not hard, but the order matters, and a few early decisions cannot be undone. Think of it like planning the foundation of a house: you can paint walls later, but you cannot move the foundation. Follow this sequence for almost any first project.

Good key management comes from a handful of repeatable habits.

flowchart TD
  ORG["Organisation policy guardrails"] --> KP["Dedicated key project"]
  KP --> KR1["Production key ring"]
  KP --> KR2["Test key ring"]
  KR1 --> K1["Key per data class"]
  AT["Application teams"] -->|"Use only"| K1
  SEC["Security team"] -->|"Manage only"| K1
  K1 --> AL["Audit logs and alerts"]
        

These habits quietly weaken key security or invite outages.

A checklist in plain words that any team can adopt.

Common mistakes beginners make

The same service serves very different needs. These scenarios show how.

flowchart LR
  T1["Tenant A data"] --> D1["Data key A wrapped"]
  T2["Tenant B data"] --> D2["Data key B wrapped"]
  T3["Tenant C data"] --> D3["Data key C wrapped"]
  D1 --> M["Master key in Cloud KMS"]
  D2 --> M
  D3 --> M
  M --> AU["Audit trail of every unwrap"]
        

An honest comparison always includes the limits.

How the options compare

When something fails, walk through the chain from permission to location to key state.

flowchart TD
  A["Operation using a key fails"] --> B{"Is the key version enabled?"}
  B -->|No| C["Enable it or use another version"]
  B -->|Yes| D{"Does the caller hold the right role?"}
  D -->|No| E["Grant the narrow role to the correct identity"]
  D -->|Yes| F{"Do key and resource locations match?"}
  F -->|No| G["Create a key in the correct location"]
  F -->|Yes| H{"Quota or size limit reached?"}
  H -->|Yes| I["Use envelope encryption, back off and retry, or raise quota"]
  H -->|No| J{"External key reachable?"}
  J -->|No| K["Restore the external connection"]
  J -->|Yes| L["Read the audit log entry for the exact reason"]
        

Symptom: a service says it cannot use the key

The most likely cause is a missing grant for the service agent. Identify the managed identity of that service in your project, grant it the encrypt and decrypt role on the key, and retry. Remember that the grant must be on the key or its key ring or project, and in the project that holds the key.

Symptom: location or region mismatch

Many services insist that the key location matches the resource location, or is a compatible multi-region or global option. If the error mentions location, create a new key ring in the correct place, because the old one cannot be moved.

Symptom: sudden failures across applications

Check whether a key or key version was disabled or scheduled for destruction. Audit logs will show who did it and when. If the destruction is still in its waiting period, restore the version, then investigate the cause before trying again.

Symptom: quota errors or slow operations

These point to too many direct operations. Move to envelope encryption, cache unwrapped data keys briefly in memory, add gradual back-off to retries, and request a quota increase well before big events.

Symptom: external key errors

Check the health of the external system, the network path to it, and the permissions it applies to incoming requests. Services using external keys fail when the external side is unreachable.

Good teams prepare for the day a key, or access to a key, falls into the wrong hands.

Nobody plans to lose control of a key, yet it happens: a service account credential leaks, an engineer with wide permissions leaves on bad terms, or an application is found to have logged something it should not. The difference between a small incident and a disaster is usually preparation. This chapter explains how to think about the problem in plain steps.

First, understand what was exposed

With Cloud KMS the raw key material normally cannot be read, so a typical incident is not “someone copied the key”. It is more often “someone gained the right to use the key”. That distinction matters. An attacker who can ask the service to decrypt data can read that data for as long as the permission lasts, but they cannot take the key away with them. Ending their access ends their ability to decrypt. This is a major safety benefit of keeping keys inside a managed service.

The response sequence

flowchart TD
  A["Suspicious key activity detected"] --> B["Confirm with audit logs"]
  B --> C{"Real incident?"}
  C -->|No| D["Document and close"]
  C -->|Yes| E["Remove suspect access"]
  E --> F["Assess exposed data from logs"]
  F --> G{"Highly sensitive data at risk?"}
  G -->|Yes| H["Temporarily disable key use"]
  G -->|No| I["Keep service running"]
  H --> J["Rotate and re-encrypt"]
  I --> J
  J --> K["Review and improve"]
        

Why preparation matters more than speed

During an incident, people are stressed and time feels short. A written runbook that lists who decides, what to disable, which dashboards to open, and who to call removes guesswork. Teams should rehearse it, in the same way a school holds fire drills, so that the first real alarm is not the first time anyone has followed the steps.

What works for one team and one key needs a few shared rules when hundreds of teams and thousands of keys share the same organisation.

A single team can remember where its keys are and who may use them. A large organisation cannot. As the number of projects grows, three problems appear together: nobody is sure who owns which key, rules are applied unevenly, and auditors ask questions that take weeks to answer. Governance is simply the habit of agreeing on a few rules and making them easy to follow and hard to ignore.

Ownership and inventory

Every key should have a named owning team and a recorded purpose. An inventory, even a simple one, answers questions such as how many keys exist, which use hardware protection, which have rotation turned on, and which have not been used for a long time. Google Cloud provides inventory and usage views, and organisations often combine them with their own records. An inventory also reveals candidates for clean-up, which keeps costs and risk down.

Guardrails through organisation policy

Organisation policies are rules set high in the hierarchy that apply to every project below. For key management, such rules can require that selected services always use customer-managed keys, and can restrict which projects are allowed to hold those keys. This turns good intentions into automatic behaviour. A team that forgets to choose a key simply cannot create the unprotected resource. When rolling out such rules, start in a limited area and give teams clear guidance, because a sudden strict rule can block legitimate work.

Mapping to compliance needs

Many industries have rules about protecting data, such as requirements for strong encryption, control over keys, regular rotation, restricted access and detailed logs. Cloud KMS supplies the building blocks, but meeting a rule is a matter of how you combine them and prove it. Auditors usually want evidence rather than promises. That evidence can include key settings, rotation records, permission lists, audit log samples and written procedures. Keep the evidence organised and refresh it on a schedule so audits become routine instead of emergencies.

Standards that pay off

A simple maturity path

A key is a stable named object with a purpose and settings. A key version is the actual secret material at one point in time. Rotation adds new versions to the same key, and applications refer to the key.

No. Key rings and keys cannot be deleted. You can disable keys and destroy key versions, which removes the actual secret material, but the names remain.

After the waiting period the material is erased permanently. Data protected only by that version cannot be decrypted again, and nobody can restore it.

Default encryption is strong and automatic. Customer-managed keys add control: you decide rotation, access and revocation, and you gain audit evidence. Choose them when you need that control or have to meet a rule.

No. New encryption uses the new version, while existing data remains under older versions until it is rewritten or deliberately re-encrypted.

It means encrypting data with a local data key and protecting that data key with a master key in Cloud KMS. Google Cloud services do this for you with customer-managed keys. Your own applications should use it for anything larger than a tiny value.

Secret Manager stores values such as passwords that your application reads back. Cloud KMS manages keys that perform operations, and the raw key is not handed to your application.

Start with software unless a rule requires hardware protection or keys outside the provider. Hardware and external options add cost and complexity.

Keep management and usage separate. A small team manages keys, applications and service agents use them, and auditors only view. Grant roles at the narrowest level.

No. Location, purpose and protection level are fixed at creation. If you chose wrongly, create a new key in the right place and move your data to it.

Use key usage and inventory views and audit logs. Check their coverage in the current documentation, and do not treat an empty result as proof that nothing depends on the key.

For most teams the cost is modest. Charges come from stored key versions and operations, with higher rates for hardware and external options. Check the current pricing page.

Cloud Key Management Service gives you a safe, managed home for encryption keys. Keys are organised into key rings inside locations, each key has a purpose and a protection level, and each key carries versions that move through clear states from enabled to destroyed. Envelope encryption lets large data be protected quickly while the master key never leaves the service. Rotation limits exposure, destruction and crypto-shredding give you powerful ways to end access, and customer-managed keys let Google Cloud services protect your data with a key you control. The strength of the whole arrangement depends on good habits: narrow permissions with separate duties, deliberate location and naming choices, careful retirement of keys, strong audit trails with alerts, and a tested plan for the day something goes wrong.