> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Keys other services can use

> Which services will encrypt their data under a key of yours, and the field each one exposes.

## 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.

<CardGroup cols={2}>
  <Card title="Secrets" icon="lock" href="/secrets#encrypting-under-your-own-key">
    Bind a secret to one of your keys at creation and every version is sealed
    under it.
  </Card>

  <Card title="Telemetry" icon="activity" href="/telemetry">
    A log group or trace setting takes a `kms_key_crn`; each ingest batch gets
    its own data key wrapped under yours.
  </Card>

  <Card title="Queues" icon="inbox">
    A queue takes a `kms_key_id`, and reuses each data key for a bounded
    period rather than minting one per message.
  </Card>

  <Card title="Registry" icon="box">
    A repository takes an `encryption_type` of `kms` plus a `kms_key_id`, and
    layer bytes are sealed under it.
  </Card>
</CardGroup>

<Warning>
  **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.
</Warning>

<Note>
  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.
</Note>