Cloud KMS

This page describes how Cloud KMS maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior.

​

Supported environments

API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on.

​

How the targets compare

Each row compares a capability of Cloud KMS with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On AWS

​

KMS Keys

Cloud KMS key rings and keys map to AWS KMS, with encrypt and decrypt requests handled by the Tensor9 adapter. Both the adapter and AWS KMS must be available for these requests to succeed.

​

Key identity and existing ciphertext

The adapter resolves the source key identifier and submits the cryptographic operation to the target service. A newly created key with the same display name has different key material and cannot decrypt earlier ciphertext. Arrange a permitted key import or re-encryption process before retiring the source key.

​

Permissions and key lifecycle

Authorize both access to the adapter and use of the target key. Test the application’s algorithms, version references, and rotation behavior. Disabling or destroying a key can affect later reads of old data, so verify those effects before changing the key lifecycle policy.

​

Compatibility differences

AWS KMS does not expose individual versions of a rotated key. Requests to encrypt with a chosen version, or disable only one version, therefore have no equivalent. The build identifies rotation periods shorter than 90 days instead of silently rounding them up.

​

On Azure

​

Key Vault

Cloud KMS keys map to Azure Key Vault, which exposes individual key versions. Asymmetric keys support signing and verification.

​

Key identity and existing ciphertext

The adapter resolves the source key identifier and submits the cryptographic operation to the target service. A newly created key with the same display name has different key material and cannot decrypt earlier ciphertext. Arrange a permitted key import or re-encryption process before retiring the source key.

​

Permissions and key lifecycle

Authorize both access to the adapter and use of the target key. Test the application’s algorithms, version references, and rotation behavior. Disabling or destroying a key can affect later reads of old data, so verify those effects before changing the key lifecycle policy.

​

Compatibility differences

The build rejects symmetric keys, including the Cloud KMS default. Standard Key Vault does not store symmetric keys; Azure Managed HSM does, but this mapping does not use it. Deleted vaults and keys retain their names until purged, which affects attempts to recreate them.

​

Existing data and credentials

Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application’s endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target.

​

Configure, tune and debug

Start with setup and configuration. Use tuning to understand supported request tags, debugging to investigate a request, and High Fidelity Cloud Emulators to validate a bounded reproduction.