Skip to content
Documentation
Key Management Service
Integrations

KMS integrations

KMS is a shared cryptographic layer for other Thalassa Cloud services. You can also use KMS directly through the API for custom application workflows.

Secrets Manager

Secrets Manager uses KMS to encrypt secret values at rest.

How it works

  • Every secret is bound to one KMS key at creation. The binding is immutable.
  • Secret values are encrypted with the bound symmetric KMS key (aes*, chacha20-poly1305 types).
  • When Secrets Manager reads or writes a secret value, it calls KMS encrypt and decrypt on your behalf.

Requirements

RequirementDescription
Secrets featureSecrets Manager must be enabled for your organisation
KMS featureKMS must be enabled for your organisation
Regional KMSKMS must be available in the secret’s region
IAMPrincipals need permissions on both the secret and the bound KMS key

Audit

Encrypt and decrypt audit events (kms.encrypt, kms.decrypt) are emitted when Secrets Manager accesses secret values. Correlate these with Secrets Manager audit entries for full traceability.

Key selection

Create a dedicated symmetric KMS key per environment or sensitivity tier—for example, separate keys for production and staging secrets. See Creating keys, Key types, and Secrets Manager getting started.

DNS DNSSEC

Thalassa Cloud DNS DNSSEC uses KMS for zone signing keys. See DNSSEC for enabling signing and DS delegation.

How it works

  • Zone signing uses a regional asymmetric KMS key as the Key Signing Key (KSK).
  • Supported signing types: ecdsa-p256, ecdsa-p384, rsa-2048, rsa-3072, rsa-4096.
  • When you enable DNSSEC on a zone without specifying a key, Thalassa DNS auto-provisions an ecdsa-p256 KMS key named DNSSEC {zone.name}.

Requirements

RequirementDescription
DNS featureDNS must be enabled for your organisation
KMS featureKMS must be enabled for your organisation
Regional KMSKMS must be available in the zone’s region

Key retention

Disabling DNSSEC on a zone does not delete the KMS key. The key remains in your organisation for audit, reuse, or manual cleanup. Review keys periodically and delete unused DNSSEC keys through the key lifecycle APIs when appropriate.

Custom signing keys

To use your own KSK, specify an existing asymmetric KMS key when enabling DNSSEC instead of relying on auto-provisioning.

Direct API usage

Beyond platform integrations, use KMS directly for:

  • Application envelope encryption
  • Webhook HMAC authentication
  • Custom code and document signing
  • BYOK migrations from other environments

See Getting started and the API reference.

Feature availability

Each integration requires its own feature gate in addition to KMS. If either service is disabled, operations fail with the appropriate HTTP error for that service.

Check KMS availability per region with GET /v1/kms/summary before provisioning dependent resources.

Related documentation

Audit logBilling