Skip to main content

​
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_crn; each ingest batch gets its own data key wrapped under yours.

Queues

A queue takes a kms_key_id, and reuses each data key for a bounded period rather than minting one per message.

Registry

A repository takes an encryption_type of kms plus a kms_key_id, and layer bytes are sealed under it.
The field is not spelled the same everywhere. Telemetry takes a kms_key_crn — the full crn:kms:<region>:<account>:key/<name>. Secrets, queues and the registry take a kms_key_id, which is the key’s UUID. Send the shape the field is named for; they are not interchangeable.
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.