Keys other services can use
Some services will encrypt their data under a key of yours instead of a platform-managed one, which puts the kill switch in your hands: disable the key and that service stops being able to read what it stored.Secrets
Bind a secret to one of your keys at creation and every version is sealed
under it.
Telemetry
A log group or trace setting takes a
kms_key; each ingest batch gets
its own data key wrapped under yours.kms_key: a UUID, account-scoped name, or full
crn:kms:<region>:<account>:key/<name>. The key must belong to the authenticated
account and the same region. Responses preserve the bound key’s identity.
Bindings retain the original key identity. Reusing a key name never transfers an existing binding to the new key.
Not everything encrypted at rest uses a key of yours. A certificate’s private
key, for example, is encrypted under a platform-managed regional key you do
not control. Where a service supports your own key, it exposes a field for
it — if there is no such field, there is no such binding.
409 KMS_KEY_IN_USE while another resource, retained encrypted data, or an encrypted write in progress still depends on the key. Changing a resource’s current key does not remove the dependency of older ciphertext. A secret keeps its binding throughout its recovery window. Secret metadata exposes the key as a kms_key ResourceRef (id, crn, name).