Secret Manager

This page describes how Secret Manager 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 Secret Manager with its adaptation on each target. A dash means this profile does not state the capability for that target.

​

Cloud Adapter

​

On AWS

​

Secrets Manager

Secrets and versions map to AWS Secrets Manager. The adapter translates version identifiers so clients requesting a specific version can continue adding and reading secrets.

​

Names and version references

The adapter maps source secret names and version references to target values. A request for the latest version can change after a new value is published; a request pinned to a version must continue identifying that version. Copy required values and version references explicitly, because creating the target secret does not transfer its history.

​

Access and deletion

Set permissions for secret reads separately from lifecycle administration. Check what remains recoverable after disabling or deleting a value, and how long the target reserves its name. Update rotation-event consumers where the target delivers a different event format.

​

Compatibility differences

AWS has no API that directly deletes one secret version. Removing its staging labels makes it eligible for background deletion; deleting a whole secret instead affects every version. A secret scheduled for deletion cannot be read until restored. These semantics differ from destroying one Google Secret Manager version, and the build requires acknowledgement of the difference.

​

On Azure

​

Key Vault

Secrets and versions map to Azure Key Vault, with individual versions available for adding and reading secrets.

​

Names and version references

The adapter maps source secret names and version references to target values. A request for the latest version can change after a new value is published; a request pinned to a version must continue identifying that version. Copy required values and version references explicitly, because creating the target secret does not transfer its history.

​

Access and deletion

Set permissions for secret reads separately from lifecycle administration. Check what remains recoverable after disabling or deleting a value, and how long the target reserves its name. Update rotation-event consumers where the target delivers a different event format.

​

Compatibility differences

Destroying a version disables it instead of erasing its contents. Deleted secrets retain their names until purged. Encryption is configured for the vault, so a customer-managed key per secret is unsupported; a user-managed replication policy across regions is also unsupported by this mapping.

​

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.