- Coverage by target cloud
- How the targets compare
- On Google Cloud
- On Azure
- On OCI
- On Private Kubernetes
Coverage by target cloud
How the targets compare
Each row compares a capability of KMS with its adaptation on each target. A dash means this row is not stated for that target.Max adaptation
On Google Cloud
How it works
Tensor9 runs a KMS adapter in the customer environment and setsAWS_ENDPOINT_URL_KMS to its loopback endpoint. The adapter accepts the application’s AWS SDK calls, including Encrypt, Decrypt, and GenerateDataKey, and translates them to Google Cloud KMS. The service retains the wrapping key; data-key operations can return a plaintext data key for the application to use.
Cloud KMS groups versioned keys in location-specific key rings. It supports symmetric encryption, authenticated context, asymmetric signing, HMAC, and rotation. The adapter constructs GenerateDataKey using a locally generated random key and a Cloud KMS encrypt call. KMS key-policy and grant APIs have the restrictions listed below.
The adapter translates AWS KMS requests to Google Cloud KMS.
Key identity and lifecycle
The adapter keeps durable records for AWS key identities, aliases, tags, and lifecycle state. Key creation provisions the corresponding target key. Later requests resolve the AWS identity to that key; the target service performs cryptographic operations and retains its wrapping key material. An alias is a mutable reference in adapter state. Updating it changes which key subsequent alias-based requests select; it does not move key material or rewrite existing ciphertext. Back up adapter state and retain the target keys and versions needed to decrypt stored data. Scheduled deletion records a recovery window of 7-30 days, with 30 days as the default. Cancelling the request returns the key to a disabled state; enable it explicitly before using it again. Final target destruction follows the target’s retention rules, which may delay physical removal beyond the adapter’s recovery window.The key ring and its crypto keys
A Cloud KMS key belongs to a key ring in a location. Each key has immutable versions, with a primary version for symmetric encryption. The adapter resolves AWS key IDs togoogle_kms_crypto_key resources and maintains alias/… mappings because Cloud KMS has no native alias object.
The key ring’s location controls where cryptographic operations run, for example us-east1 or the us multi-region. Symmetric encryption uses the primary version; decryption uses the version recorded in the ciphertext. Signing, MAC, and public-key export operations address a specific version.
A location-specific key ring holds versioned keys. Symmetric encryption uses the primary version.
One purpose per key: symmetric, asymmetric, and MAC
CreateKey translates AWS key usage and specification into a Cloud KMS purpose and version_template.algorithm. Symmetric ENCRYPT_DECRYPT uses GOOGLE_SYMMETRIC_ENCRYPTION; signing uses ASYMMETRIC_SIGN with an RSA or EC algorithm; HMAC uses MAC. Purpose is fixed at creation.
Symmetric keys use cryptoKeys.encrypt and decrypt. Signing uses asymmetricSign; verification checks the signature against the public key returned by getPublicKey. HMAC uses macSign and macVerify. A request incompatible with the key’s purpose returns an error.
Key purpose selects encryption, signing, or MAC operations and their algorithms.
How GenerateDataKey works
GenerateDataKey returns a plaintext data key and an encrypted (wrapped) copy. The application uses the plaintext key to encrypt its data locally, then discards that key and stores the wrapped copy beside the encrypted data. To read the data later, it asks the key service to decrypt the wrapped key.
The adapter generates a random data key of the requested size and calls cryptoKeys.encrypt to wrap it. It returns the AWS-shaped {Plaintext, CiphertextBlob} pair and uses cryptoKeys.decrypt to unwrap it later. Both calls include the encryption context as AAD. The adapter includes key identity with Cloud KMS ciphertext so Decrypt can locate the key. Applications must treat this blob as opaque.
The adapter generates a random data key and wraps it with cryptoKeys.encrypt .
Encryption context and authenticated data
An encryption context is a non-secret key/value map bound to ciphertext as additional authenticated data (AAD). Decryption requires the same context. Applications can use it to bind encrypted values to a tenant or purpose. Cloud KMS accepts up to 64 KiB ofadditionalAuthenticatedData. The adapter serializes the context map into a stable byte encoding so map insertion order does not affect decryption. It supplies the same encoding for direct encryption and data-key wrapping. A different context causes decryption to fail.
The adapter encodes the encryption context as additionalAuthenticatedData . Decryption requires the same context.
Rotation without breaking old ciphertexts
Key rotation creates a new version for subsequent encryption. Retained, enabled older versions remain available to decrypt existing ciphertext.rotation_period schedules new key versions and promotes each to primary. RotateKeyOnDemand creates and promotes a version immediately; GetKeyRotationStatus reports whether a rotation period is configured. Previous enabled versions remain usable until disabled or destroyed.
Rotation creates a primary version for new encryption. Earlier enabled versions can still decrypt existing data.
Limitations
Access policies and grants. The mapping uses Google IAM for target-key access and does not reproduce AWS key-policy or grant APIs. Constrained grants are rejected; encryption-context authentication alone does not replace a grant that limits permitted callers or contexts. Ciphertext format. The adapter wraps Cloud KMS ciphertext with the key identity needed for a later Decrypt request. Treat CiphertextBlob as opaque. Existing AWS ciphertext is not directly decryptable with a new Google key. Import and regions. Import material through the configured Cloud KMS import job. AWS runtime import-handshake APIs are outside this mapping. A key-ring location does not provide independently addressable AWS multi-region replica keys. Composed operations. GenerateDataKey generates a random key and wraps it with Cloud KMS. ReEncrypt decrypts and encrypts under the destination key; plaintext exists temporarily in the adapter but is not returned to the caller. DeriveSharedSecret is outside this mapping.Other considerations
Configure access and protection. Grant the deployment identity the required Cloud KMS operations at the appropriate key or key-ring scope. Workload identity supplies credentials. Google operates the key service; choose software or HSM protection for the required keys. Keep data recoverable. Retain old key versions while ciphertext requires them. Preserve adapter identity and alias records alongside the target-key inventory. Test disable, cancellation, rotation, and recovery before changing production key state. Migrate ciphertext. Use the old AWS key to decrypt ciphertext or unwrap data keys, then encrypt or wrap under the target key. Keep AWS available until migration and target decryption are verified. Provisioning a key does not transform stored ciphertext.On Azure
How it works
Tensor9 runs a KMS adapter in the customer environment and setsAWS_ENDPOINT_URL_KMS to its loopback endpoint. The adapter accepts the application’s AWS SDK calls, including Encrypt, Decrypt, and GenerateDataKey, and translates them to Azure Key Vault. The service retains the wrapping key; data-key operations can return a plaintext data key for the application to use.
A standard Key Vault supports RSA and EC keys. It handles asymmetric signing and RSA encryption, but has no symmetric AES or HMAC key type. The adapter implements data-key generation with RSA wrapping. Requests with an encryption context are rejected because this RSA path cannot bind AAD. Azure Managed HSM is a separate symmetric-key service. Key Vault Premium also offers oct-HSM AES/HMAC in public preview. Neither is part of this Standard RSA/EC mapping.
The adapter translates AWS KMS requests to an Azure Key Vault key.
Key identity and lifecycle
The adapter keeps durable records for AWS key identities, aliases, tags, and lifecycle state. Key creation provisions the corresponding target key. Later requests resolve the AWS identity to that key; the target service performs cryptographic operations and retains its wrapping key material. An alias is a mutable reference in adapter state. Updating it changes which key subsequent alias-based requests select; it does not move key material or rewrite existing ciphertext. Back up adapter state and retain the target keys and versions needed to decrypt stored data. Scheduled deletion records a recovery window of 7-30 days, with 30 days as the default. Cancelling the request returns the key to a disabled state; enable it explicitly before using it again. Final target destruction follows the target’s retention rules, which may delay physical removal beyond the adapter’s recovery window.RSA and EC keys
The adapter uses anazurerm_key_vault_key. CreateKey selects an RSA key size or EC curve through key_type, key_size, and curve. The key_opts list restricts the key to operations such as encrypt, decrypt, wrapKey, unwrapKey, sign, and verify. Requests for symmetric AES keys are rejected.
DescribeKey uses Get Key to report identifier, type, size or curve, permitted operations, and validity. EnableKey and DisableKey update the enabled attribute. The adapter stores the AWS key description as a tag and maintains alias/… mappings. Key Vault retains immutable key versions.
key_opts restricts operations on the RSA or EC key. Standard vaults do not support symmetric AES keys.
Envelope encryption via wrapKey / unwrapKey
GenerateDataKey returns a plaintext data key and an encrypted (wrapped) copy. The application uses the plaintext key to encrypt its data locally, then discards that key and stores the wrapped copy beside the encrypted data. To read the data later, it asks the key service to decrypt the wrapped key.
The adapter generates a random data key, wraps it through RSA-OAEP wrapKey, and returns plaintext and encrypted copies. unwrapKey recovers it later. This uses an RSA wrapping key; it does not provide a symmetric AES KMS key.
The adapter generates a data key, uses RSA wrapKey to encrypt it, and uses unwrapKey to recover it.
Encryption-context limitations
An encryption context is a non-secret key/value map bound to ciphertext as additional authenticated data (AAD). Decryption requires the same context. Applications can use it to bind encrypted values to a tenant or purpose. The standard-vault RSA-OAEP path has no AAD parameter for an AWS encryption context. Context-bearing requests return errors. Applications that require context binding need a supported AES-GCM service, such as the separate Azure Managed HSM service.
The standard-vault RSA path cannot bind an encryption context, so context-bearing requests are rejected.
Supported key types
AWS KMS distinguishes symmetric encryption keys, asymmetric RSA or EC keys, and HMAC keys. Standard Azure Key Vault supports the asymmetric family. Its RSA key size limits the amount of data that can be encrypted in one operation.Sign, Verify, GetPublicKey, and RSA Encrypt/Decrypt use Key Vault operations. Data keys use RSA wrapping. Symmetric AES key creation, encryption-context binding, and GenerateMac/VerifyMac are unsupported on this standard-vault path.
Key Vault Standard supports RSA and EC keys. Symmetric-key options use other Azure configurations.
Rotation via a key rotation policy
Key rotation creates a new version for subsequent encryption. Retained, enabled older versions remain available to decrypt existing ciphertext. The key’s rotation policy setsexpire_after and a time_after_creation or time_before_expiry trigger. EnableKeyRotation configures it, GetKeyRotationStatus reads it, and RotateKeyOnDemand creates a new version immediately. Previous usable versions remain available for decryption. Removing access to an old key prevents decryption of data encrypted under it.
Rotation creates a key version while retaining older versions for existing ciphertext.
Limitations
Standard-vault algorithms. This mapping uses RSA and EC keys in Key Vault Standard. RSA encryption has a payload limit determined by its modulus and padding. Data-key generation uses RSA wrapping; the wrapping key is not a symmetric AES key. Authenticated context and HMAC. The mapped RSA-OAEP operations cannot authenticate an AWS encryption context and reject context-bearing requests. Standard vaults have no HMAC key type. Azure Managed HSM supports symmetric keys; Key Vault Premium also offers oct-HSM AES/HMAC in public preview, outside this Standard mapping. Authorization and import. AWS grant and key-policy APIs are not recreated. Use Azure role assignments for target access. Imported material uses the provider key-import procedure; the AWS runtime import handshake is outside this mapping. Regions and retention. This mapping does not create shared-material AWS multi-region replica keys. The adapter recovery window and the vault’s native soft-delete retention are distinct; native retention and purge protection can delay final removal.Other considerations
Choose key protection. Key Vault Premium can protect RSA and EC keys with an HSM; Managed HSM is a separate service. The Standard RSA/EC profile described here does not claim their additional symmetric-key capabilities. Grant access. Use the deployment’s Azure identity and narrowly scoped role assignments. Separate permission to manage keys from permission to decrypt or unwrap data keys. Retain and migrate. Keep old key versions available while ciphertext requires them. Decrypt or unwrap AWS values with the old key and encrypt or wrap under the new key before retiring AWS access. Test context requirements early: this RSA mapping cannot preserve them.On OCI
How it works
Tensor9 runs a KMS adapter in the customer environment and setsAWS_ENDPOINT_URL_KMS to its loopback endpoint. The adapter accepts the application’s AWS SDK calls, including Encrypt, Decrypt, and GenerateDataKey, and translates them to OCI KMS. The service retains the wrapping key; data-key operations can return a plaintext data key for the application to use.
OCI KMS supports symmetric AES keys, authenticated encryption context, asymmetric signing, and a native data-key generation operation. HMAC and AWS key-policy and grant APIs are unsupported; key access uses OCI IAM.
The adapter translates AWS KMS requests to OCI KMS.
Key identity and lifecycle
The adapter keeps durable records for AWS key identities, aliases, tags, and lifecycle state. Key creation provisions the corresponding target key. Later requests resolve the AWS identity to that key; the target service performs cryptographic operations and retains its wrapping key material. An alias is a mutable reference in adapter state. Updating it changes which key subsequent alias-based requests select; it does not move key material or rewrite existing ciphertext. Back up adapter state and retain the target keys and versions needed to decrypt stored data. Scheduled deletion records a recovery window of 7-30 days, with 30 days as the default. Cancelling the request returns the key to a disabled state; enable it explicitly before using it again. Final target destruction follows the target’s retention rules, which may delay physical removal beyond the adapter’s recovery window.The Vault and its master keys
An OCI Vault holds master encryption keys.protection_mode selects SOFTWARE, HSM (a hardware security module), or EXTERNAL (a reference to an external key manager). DEFAULT vaults share an HSM partition; VIRTUAL_PRIVATE vaults have a dedicated partition.
The adapter uses two OCI clients. Cryptographic requests, including encryption, decryption, data-key generation, and signing, use crypto_endpoint. Key creation, rotation configuration, and scheduled deletion use management_endpoint.
Cryptographic requests use crypto_endpoint ; key management uses management_endpoint .
The native single-call envelope
GenerateDataKey returns a plaintext data key and an encrypted (wrapped) copy. The application uses the plaintext key to encrypt its data locally, then discards that key and stores the wrapped copy beside the encrypted data. To read the data later, it asks the key service to decrypt the wrapped key.
GenerateDataEncryptionKey returns both plaintext and ciphertext when include_plaintext_key is true. With it false, the call returns only the wrapped key, corresponding to GenerateDataKeyWithoutPlaintext. The adapter translates these results to AWS response fields without generating the data key locally.
GenerateDataEncryptionKey returns a plaintext data key and its encrypted copy in one call.
The encryption context, bound as associated data
An encryption context is a non-secret key/value map bound to ciphertext as additional authenticated data (AAD). Decryption requires the same context. Applications can use it to bind encrypted values to a tenant or purpose. The adapter sends the encryption context as OCIassociatedData. AES-GCM authenticates it with the ciphertext. Decryption with different associated data fails authentication.
OCI authenticates associatedData with the ciphertext. A different context causes decryption to fail.
Symmetric and asymmetric keys
An OCI key’skey_shape specifies algorithm (AES, RSA, or ECDSA), length, and a curve_id where applicable. These correspond to AWS symmetric encryption and asymmetric key families.
AES keys support Encrypt, Decrypt, and GenerateDataEncryptionKey. RSA and ECDSA keys support signing, verification, and public-key export. OCI has no HMAC key type, so GenerateMac and VerifyMac return unsupported-operation errors.
OCI supports AES, RSA, and ECDSA key types. HMAC is unsupported.
Rotation
Key rotation creates a new version for subsequent encryption. Retained, enabled older versions remain available to decrypt existing ciphertext.is_auto_rotation_enabled and rotation_interval_in_days configure automatic rotation. RotateKeyOnDemand creates a version immediately. New encryption uses the new version; decryption of existing ciphertext uses its recorded version. Both AWS and OCI express the rotation interval in days.
Automatic or on-demand rotation creates a version for new encryption and retains previous versions.
Limitations
Authorization and HMAC. Target access uses OCI IAM; AWS key-policy and grant APIs are not recreated. OCI key shapes in this mapping are AES, RSA, and ECDSA, without an HMAC key type. Replication scope. OCI vault replication copies a vault rather than one independently managed key. ReplicateKey therefore has broader scope; UpdatePrimaryRegion does not move an individual key’s primary region. Deletion timing. The adapter records the requested 7-30-day recovery window and translates the date to OCI’s time_of_deletion. Retain the keys and versions required by existing ciphertext before scheduling destruction. Imported material. OCI imports externally generated material through its wrapping-key and key-import workflow. That differs from protection_mode=EXTERNAL, which references a key manager outside OCI. The AWS runtime import handshake is outside this mapping.Other considerations
Configure custody and access. Choose the vault and each key’s software, HSM, or external protection configuration. Oracle operates the managed service; the customer configures keys, compartment permissions, and deployment identity. Retain versions. Rotation creates a version for new encryption. Existing ciphertext needs its original version. Plan recovery and replication for the vault holding those versions, and verify access from the destination environment. Migrate ciphertext. Decrypt AWS ciphertext or unwrap its data keys with the old key, then encrypt or wrap through the target adapter. Keep AWS available until migration and target decryption are verified. Creating an OCI key does not transfer AWS material or ciphertext.On Private Kubernetes
How it works
Tensor9 runs a KMS adapter in the customer environment and setsAWS_ENDPOINT_URL_KMS to its loopback endpoint. The adapter accepts the application’s AWS SDK calls, including Encrypt, Decrypt, and GenerateDataKey, and translates them to HashiCorp Vault Transit. The service retains the wrapping key; data-key operations can return a plaintext data key for the application to use.
Vault Transit performs cryptographic operations within Vault and retains its wrapping keys there. It supports data-key generation, rewrapping, signing, verification, and HMAC. You operate the Vault cluster, including storage, unsealing, authentication, and the Transit mount; Tensor9 operates the KMS adapter.
The adapter serves the AWS KMS API using Vault Transit in the customer environment.
Key identity and lifecycle
The adapter keeps durable records for AWS key identities, aliases, tags, and lifecycle state. Key creation provisions the corresponding target key. Later requests resolve the AWS identity to that key; the target service performs cryptographic operations and retains its wrapping key material. An alias is a mutable reference in adapter state. Updating it changes which key subsequent alias-based requests select; it does not move key material or rewrite existing ciphertext. Back up adapter state and retain the target keys and versions needed to decrypt stored data. Scheduled deletion records a recovery window of 7-30 days, with 30 days as the default. Cancelling the request returns the key to a disabled state; enable it explicitly before using it again. Final target destruction follows the target’s retention rules, which may delay physical removal beyond the adapter’s recovery window.The Transit engine and its versioned keys
Transit receives plaintext or ciphertext and returns the result of the requested operation. Encryption and wrapping keys remain in Vault; generated plaintext data keys can be returned to applications. Rotating a Transit key creates a version for new encryption and retains older versions. Therewrap operation updates ciphertext to the latest version; min_decryption_version controls which older versions may still decrypt.
Transit performs cryptographic operations in Vault and retains versioned wrapping keys there.
The native data key and rewrap
GenerateDataKey returns a plaintext data key and an encrypted (wrapped) copy. The application uses the plaintext key to encrypt its data locally, then discards that key and stores the wrapped copy beside the encrypted data. To read the data later, it asks the key service to decrypt the wrapped key. Transit implements this with /transit/datakey/plaintext/:name; /transit/datakey/wrapped/:name returns only the encrypted copy for GenerateDataKeyWithoutPlaintext.
For rewrapping under the same Transit key, /transit/rewrap/:name decrypts the stored value and encrypts it with the current key version within Vault. It does not return plaintext to the caller. A different destination key or changed context requires a decrypt-and-encrypt sequence through the adapter, where plaintext is held temporarily.
The data-key endpoint returns a plaintext key and its encrypted copy. Rewrap updates the encrypted copy without returning plaintext.
Signing, verification, and HMAC
Transit key types include symmetricaes256-gcm96 and asymmetric rsa, ecdsa, and ed25519. Symmetric keys support encryption, data-key wrapping, rewrap, and HMAC. Asymmetric keys support signing, verification, and public-key export.
GenerateMac and VerifyMac use Transit’s server-side HMAC operations. DeriveSharedSecret is unsupported because Transit has no corresponding endpoint.
Transit supports encryption, data keys, rewrap, signing, verification, and HMAC.
Encryption context, bound as associated data
An encryption context is a non-secret key/value map bound to ciphertext as additional authenticated data (AAD). Decryption requires the same context. Applications can use it to bind encrypted values to a tenant or purpose. The adapter sends encryption context asassociated_data for encryption, decryption, rewrap, and data-key generation. A mismatch causes decryption to fail. This differs from Transit’s context parameter, which is used for key derivation.
Transit authenticates the encryption context through associated_data . Decryption requires the same context.
Minimum decryption version
Key rotation creates a new version for subsequent encryption. Retained, enabled older versions remain available to decrypt existing ciphertext. Transit’smin_decryption_version limits which retained versions can decrypt. Its usual value of 1 permits all versions. Raising it prevents decryption of ciphertext using a lower version; rotation alone does not impose that restriction.
The adapter keeps min_decryption_version = 1 on the keys it manages. Raising it or destroying an old version prevents access to affected ciphertext and must be handled as a separate change.
The adapter sets min_decryption_version = 1 . Raising it prevents older versions from decrypting their ciphertext.