On this page
A customer-managed key is an encryption key that lives in a cloud provider's key management service under your account's control, and that the provider's other services use to encrypt and decrypt your data, giving you authority over the key's policy, rotation and deletion while the provider's service still performs the decryption.
The three kinds of keys
AWS distinguishes three types, and the differences are about control, not about who decrypts (AWS KMS):
| Customer managed | AWS managed | AWS owned | |
|---|---|---|---|
| Key policy | "exclusively controlled by the customer" | controlled by the service, viewable by you | controlled and viewable only by the service |
| Use logged in your CloudTrail | yes | yes | no |
| You can disable or delete it | yes | no | no |
Google uses the term CMEK, customer-managed encryption keys, "encryption keys that you own", which give "ownership and control of the keys that protect your data at rest in Google Cloud" (Google Cloud). "Bring your own key" (BYOK) is used for similar arrangements in which you supply or control the key material; the question of who decrypts is the same.
What you actually control
- Who may use the key, through the key policy and IAM.
- Visibility: every use shows up in your audit log.
- The off switch. Google: "if you disable or destroy the CMEK, that data can't be accessed." That is a real power, for example when leaving a provider or responding to an incident.
What you don't control
Decryption still happens inside the provider's service. Google describes it plainly: "the operations to encrypt and decrypt resources are handled by the resource service agent", and when someone requests a resource, "the service agent automatically attempts to decrypt the requested resource." While the key is enabled, the service decrypts for whoever your IAM rules allow, and those rules are administered by people in your cloud account.
So a customer-managed key answers "who controls the key?" It doesn't change the answer to "who can read the data?", which still includes the cloud service and anyone with sufficient permissions in your account.
Common mistakes
- Reading CMK as end-to-end encryption. It isn't; the provider decrypts.
- Granting the key to broad roles. Then the control you paid for is spread thin.
- Disabling a key without a plan. Google warns that some services "can experience permanent data loss" if the key stays disabled too long.
Crunu and customer-managed keys
Crunu doesn't use a cloud KMS for your values, so there is no customer-managed key to configure. The keys that decrypt Crunu environments are held by the people and machines you grant access to, sealed to their public keys; the server stores only ciphertext and has no decryption key at any point. In that sense every key is customer-held, and no service, including Crunu's, can decrypt on request. The cost is that Crunu can't do things that need a server-side key, such as dynamic secrets or server-run syncs.
The question in detail, with quotes from AWS, Google and Microsoft, is in customer-managed keys don't stop the cloud from decrypting and who can decrypt your secrets?.
Sources
- AWS KMS: AWS KMS keys, checked October 30, 2026.
- Google Cloud: Customer-managed encryption keys (CMEK), 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