On this page
A key management service (KMS) is a managed system that creates and stores encryption keys and performs cryptographic operations with them, such as encrypting, decrypting and signing, on behalf of authorized callers, so that applications use keys through an API without ever holding the key material themselves.
How a cloud KMS works
AWS describes its service as one "that makes it easy for you to create and control the keys used to encrypt and sign your data", and says KMS keys are protected by FIPS 140-3 validated hardware security modules and "never leave AWS KMS unencrypted" (AWS KMS). Other clouds offer comparable services.
Most uses follow envelope encryption:
- A service asks the KMS for a data key.
- The KMS returns the data key in plain form and also encrypted under a KMS key.
- The service encrypts the data with the plain data key, discards it, and stores the encrypted data key next to the data.
- To read the data, the service sends the encrypted data key back to the KMS, which decrypts it if the caller is allowed.
AWS Secrets Manager does exactly this: on GetSecretValue, it "decrypts the secret value before returning it to the caller", using KMS to unwrap the data key (AWS Secrets Manager).
What a KMS protects, and what it doesn't
A KMS is very good at one thing: the key itself can't be copied out. Stealing a database of encrypted data keys gives an attacker nothing without KMS access, and every use of a key is logged.
It doesn't decide who should read the data. It answers whoever its policies allow. If a service in your account can call Decrypt, so can anyone who controls that service or holds permissions to call it directly. The question "who can decrypt?" becomes "who has the right IAM permissions?", and that includes administrators in your cloud account and the cloud services you've authorized.
Common mistakes
- Treating "encrypted with KMS" as "unreadable". It is unreadable to someone without KMS permissions, which is not the same as unreadable to the service or your admins.
- Broad key policies. A key usable by every role in the account protects against very little.
- One key for everything. Separate keys per data set make permissions and audit meaningful.
Crunu and KMS
Values stored in Crunu don't pass through any KMS. They are encrypted on people's devices and in the crunu agent, with environment keys sealed to each recipient's public key; there is no service, KMS or otherwise, that can decrypt them on request. Crunu doesn't use an HSM or a KMS for those keys either: the cryptography runs in the browser, through WebCrypto, and in the agent.
A self-hosted Crunu server does use a cloud's secret store for its own settings on some platforms, for example Google Secret Manager for SERVER_KEY on Cloud Run. Those protect sessions and tokens, not environment values. How the models compare across 18 tools is in who can decrypt your secrets?.
Sources
- AWS Key Management Service: overview, checked October 30, 2026.
- AWS Secrets Manager: Secret encryption and decryption, checked October 30, 2026.
From the blog
Security
Customer-managed keys don't stop the cloud from decrypting
With a customer-managed key, AWS, Google Cloud and Azure still decrypt your secrets to serve them. What CMEK really controls, and when that is enough.
Who can decrypt guide
Teams
Removing someone from git-crypt, SOPS or Ansible Vault
None of the three can take back access someone already had. What each tool does when a person leaves, in what order, and why old commits stay readable.
Offboarding guide
Secrets
Should you commit .env files? What belongs in Git
Commit the template, never the values. Which .env files go in Git, what frameworks say, encrypted .env files, and where the real values should live.
Sharing .env files guide