Google Cloud KMS

Encrypting data requires a key, but leaving that key in code or long-lived environment variables just creates another secret to manage badly. Key changes and access tracking also become manual quickly.

Teams stored encryption keys in config files or shared HSMs across departments with no audit trail. When a key needed rotation, every application that referenced it had to be updated manually. A leaked key meant no way to know which data was compromised or which services had used it. Cloud KMS centralized the entire key lifecycle: keys live in one place with automatic rotation schedules and per-request audit logging, so a rotation or a breach investigation no longer requires touching every application individually.

Cloud KMS organizes keys in a hierarchy. Key Rings group related keys together, for example all keys belonging to one application. Inside a Key Ring, each Crypto Key holds multiple Key Versions. When you rotate a key, a new version is created automatically. New data encrypts with the latest version, while data encrypted with a previous version still decrypts correctly using that older version. Applications call the encrypt or decrypt API, IAM policies control who can use each key, and every call is written to audit logs.

Cloud KMS and Secret Manager both handle sensitive material, but KMS manages encryption keys while Secret Manager stores application secrets. Use KMS when you need to encrypt data directly; use Secret Manager when you need to inject passwords or API tokens into runtimes.

A good fit for personal, payment, and other regulated data that must be encrypted directly. It does not by itself handle how applications receive readable passwords or API tokens at runtime.