Cloud Secrets Managers Guide: AWS, Azure and Google Cloud Compared

A cloud secrets manager only protects a credential if the identities allowed to read it are as tightly scoped as the secret is sensitive. AWS Secrets Manager, Azure Key Vault and Google Secret Manager all encrypt secrets at rest, version them and log access, but each has a different permission model, a different idea of what "rotation" means and different defaults for replication and deletion. Most real compromises do not break the vault: they use a workload or human identity that was already allowed to read far more than it needed. This guide compares the three native services from their own documentation, explains how rotation, access control, replication and auditing work in each, and sets out an implementation and detection approach for platform and security engineers who run them. For the wider programme (discovery, policy, tool selection) see the Secrets Management Guide and the Secrets Management Buyer's Guide.

Key takeaways

• The reader is the risk. Every secret in a cloud secrets manager is ultimately protected by an IAM grant to a role, managed identity or service account, so the non-human identities that read secrets are the real control surface.
• Rotation means different things. AWS runs the rotation workflow for you (managed or Lambda based), Azure Key Vault raises a SecretNearExpiry event for you to act on, and Google Secret Manager sends a SECRET_ROTATE Pub/Sub message and leaves the new value to your code.
• Scope grants at the secret or vault, not the account. A Google Secret Accessor grant at folder or organisation level reads every secret below it, and an AWS role with secretsmanager:GetSecretValue on * does the same for an account.
• Control-plane roles can become data-plane access. In Azure Key Vault's legacy access policy model, a principal with Contributor on the vault can grant itself data access; the Azure RBAC permission model closes that path.
• Read events are the detection signal. GetSecretValue and BatchGetSecretValue in CloudTrail, SecretGet in Key Vault AuditEvent logs and AccessSecretVersion in Google Data Access logs are where bulk dumping shows up, so make sure they are collected.

Why secrets managers are an NHI problem

A secrets manager moves a credential out of code and configuration and puts an identity check in front of it. That check is an IAM decision about a non-human identity: an EC2 instance profile or Lambda execution role in AWS, a managed identity or service principal in Azure, a service account in Google Cloud. The secret itself is usually a second credential (a database password, a third-party API key, a signing key), so a single over-permitted workload identity can unlock many downstream systems.

• Chained credentials: the workload identity authenticates to the cloud provider, then reads a secret that authenticates somewhere else. Compromise of the first gives the second. In the AI Agent Retail Card Theft Campaign 2026, an attacker that reached a second host dumped 46 secrets from AWS Secrets Manager, every secret that host could reach, and used them to get into the commerce database.
• What the vault does not solve: secrets copied into environment variables, CI logs or container images after retrieval, and hard-coded keys that were never moved into the vault. Those are secret sprawl problems. See the Secret Sprawl Measurement Guide.
• Where possible, remove the secret: a workload that can use a managed identity, IAM database authentication or workload identity federation needs no stored secret at all. Microsoft's own rotation tutorial advises preferring Entra ID authorisation with a managed identity over shared storage account keys. See the Workload Identity Federation Guide.

MITRE ATT&CK tracks the abuse directly as T1555.006 Cloud Secrets Management Stores: an adversary with sufficient privileges calls the provider's API to read stored secrets.

AWS, Azure and Google Cloud compared

The table below is built from each provider's documentation. Feature names change; confirm against the current docs before relying on a specific limit.

Access control: who can read a secret

AWS Secrets Manager

• Identity policies: grant secretsmanager:GetSecretValue on specific secret ARNs, never on *. A secret ARN ends in a random six-character suffix, so use a name prefix with a wildcard only for that suffix.
• Resource policies: attach a policy to the secret for cross-account access, and use it to deny reads from principals outside the intended role. Changes appear in CloudTrail as PutResourcePolicy and DeleteResourcePolicy.
• Encryption key: a customer managed KMS key adds a second gate, because the reader also needs decrypt rights on that key. See the AWS IAM Policies and Roles Guide.

Azure Key Vault

• Use the Azure RBAC permission model: data-plane roles include Key Vault Secrets User (read secret contents), Key Vault Secrets Officer (any action on secrets except managing permissions), Key Vault Reader (metadata only, no secret values) and Key Vault Administrator (all data-plane operations).
• Close the Contributor path: Microsoft's documentation warns that a user with Contributor on the vault control plane can grant themselves data-plane access by setting an access policy. The Azure Key Vault Contributor Escalation 2024 showed Key Vault Contributor carries Microsoft.KeyVault/vaults/write; Microsoft classed it as by design and recommends Azure RBAC.
• Switch carefully: moving a vault to the RBAC model invalidates all access policy permissions, so assign the equivalent roles first or applications will fail.
• Scope: assign roles at vault scope, one vault per application per environment. Per-secret assignments are for exceptions such as a secret shared by several applications. See the Azure RBAC and Service Principals Guide.

Google Secret Manager

• Grant at the lowest level: Secret Accessor granted on a project reads every secret in the project; on a folder or organisation, every secret below it. Grant it on the individual secret.
• Know the basic roles: roles/owner includes secretmanager.versions.access; roles/editor and roles/viewer do not. roles/secretmanager.editor manages secrets without reading payloads.
• Separate writers from readers: roles/secretmanager.secretVersionAdder lets a rotation job add versions without reading them.
• Use IAM Conditions: restrict access by secret name prefix, specific version or time window. See the Google Cloud IAM and Service Accounts Guide.

Rotation: what each service actually does

AWS: a managed workflow

AWS offers managed rotation for many managed secrets, managed external secrets rotation for partner-held secrets, and rotation by Lambda function for everything else. A Lambda rotation function is called once per step:

1. createSecret: generate a new value and store it as a new version labelled AWSPENDING.
2. setSecret: change the credential in the database or service to match AWSPENDING.
3. testSecret: connect with the AWSPENDING value.
4. finishSecret: move AWSCURRENT to the new version; Secrets Manager labels the old one AWSPREVIOUS, which is your rollback point.

Choose the strategy deliberately. Single user is simplest and suits most cases, but there is a short window where the database may refuse the new password, so clients need retries. Alternating users clones the user and rotates the inactive one, so both credentials stay valid; it needs superuser credentials in a separate secret, and the clone keeps the permissions it had when cloned. If any step fails, Secrets Manager retries the whole rotation during the rotation window, and a stuck AWSPENDING label blocks later rotations.

Azure: event driven, you build it

Key Vault publishes SecretNearExpiry to Event Grid about 30 days before a secret's expiry date. Microsoft's dual-credential pattern uses an Azure Function with a managed identity that regenerates whichever of two keys is not in use and writes it as a new secret version, tracked with tags such as CredentialId and ValidityPeriodDays. A secret with no expiry date never triggers rotation, so set expiry on every rotatable secret.

Google: a scheduled notification

Set rotation_period (minimum one hour) and next_rotation_time, attach Pub/Sub topics, and Secret Manager sends SECRET_ROTATE on schedule. Creating the new credential, adding the version and redeploying consumers is your subscriber's job. Rotations in flight cause scheduled rotations to be skipped, and retries stop after seven days.

For the operational runbook, see the Secrets Rotation Runbook Template.

Retrieval, caching and replication

• Retrieve at runtime, not build time: secrets baked into images or deployment templates escape the vault's access control and audit trail.
• AWS Workload Credentials Provider: the open-source helper (formerly the AWS Secrets Manager Agent) runs on Lambda, ECS, EKS and EC2, serves secrets on localhost:2773, requires an X-Aws-Parameters-Secrets-Token header on every request as SSRF protection, and caches values in memory for 300 seconds by default. AWS notes there is no cache invalidation, so a rotated secret may be served stale until the TTL expires, and cached values are not encrypted. Align the TTL with the rotation strategy, or use refreshNow=true after a failed authentication.
• Replication (AWS): replica secrets carry the encrypted value and metadata, including resource policies, to other Regions; each replica can use a KMS key in its own Region; rotation runs on the primary only. GovCloud and China Regions cannot replicate to or from commercial Regions.
• Replication (Google): automatic replication lets Google choose regions; user-managed replication pins payloads to named locations, which helps with residency requirements, but write operations fail if a configured region is down. The choice is fixed at creation. See the Data Sovereignty and Residency Guide.
• Deletion (Azure): soft-delete is on by default and cannot be disabled; enable purge protection for vaults holding encryption keys, and restrict the Key Vault Purge Operator role.

Choosing between native and central secrets managers

The Buyer's Guide covers vendor evaluation; this guide stays with the native services. See the Multi-Cloud Identity Guide for the identity layer across providers.

Implementation: a phased rollout

1. Inventory: list every secret store per account, subscription and project, and every principal with read rights. Include shadow secrets managers: vaults and secrets created by teams outside the platform standard, and secrets held in parameter stores, CI variables or configuration files.
2. Set the structure: one vault per application per environment in Azure; per-application name prefixes plus tags in AWS; one project per environment, secrets per application in Google Cloud.
3. Fix the permission model: migrate Key Vault to Azure RBAC (assign roles first), remove project-level Secret Accessor grants in Google, replace Resource: "*" in AWS policies. Test with a pilot application before changing shared vaults.
4. Turn on logging: CloudTrail trails to central storage, Key Vault diagnostic settings for AuditEvent, and Data Access audit logs for Secret Manager.
5. Enable rotation in rings: start with non-production databases, then low-risk production, then shared credentials. For AWS, run a rotation and check the RotationSucceeded event; keep AWSPREVIOUS as the rollback by moving AWSCURRENT back with UpdateSecretVersionStage if consumers fail. In Azure and Google, roll back by re-enabling the previous version or pointing consumers at it.
6. Remove the secret where you can: replace stored cloud keys with managed identities, IAM roles or federation.
7. Review quarterly: recertify readers of each high-value secret with the application owner.

Detection and measurement

Alert on a single principal reading many distinct secrets in a short window, reads from an identity that has never read that secret, reads from outside expected networks, and listing followed by reads. These match T1555.006 and, once the secret is used, T1078.004 Cloud Accounts. See the Cloud Logging and Audit Trail Guide.

Metrics:

• Percentage of secrets with rotation enabled and a successful rotation inside their period.
• Number of principals with read access at account, project, folder or organisation scope (target: zero outside break-glass).
• Median readers per high-value secret.
• Percentage of Key Vaults on the Azure RBAC permission model with purge protection where keys are held.
• Percentage of stores with read events collected centrally.
• Count of workloads moved from stored cloud keys to managed identity or federation.

Common failure patterns

• Wildcard readers: a role with GetSecretValue on every secret in the account turns one compromised host into a full dump, as in the AI Agent Retail Card Theft Campaign 2026.
• Trusting role names: assuming a "management" role has no data access. Key Vault Contributor under access policies could grant itself secret access, as the Azure Key Vault Contributor Escalation 2024 showed.
• Rotation configured, never completed: Azure secrets without expiry dates, Google SECRET_ROTATE messages with no subscriber, AWS functions stuck on AWSPENDING.
• Vaulting the key that unlocks the vault: a long-lived access key or service account key stored next to the application so it can read the secrets manager. In the LastPass Breach 2022, AWS access keys and backup decryption keys held in one engineer's vault unlocked the company's cloud storage of customer vault backups.
• Data access logging off: Google Data Access logs and Key Vault diagnostic settings must be enabled, so reads are invisible until they are.
• Stale caches after rotation: long client-side TTLs that serve the old credential after rotation, causing outages that push teams to disable rotation.

Framework mapping

For how secrets readers rank among wider NHI risks, see the Top 10 NHI Risks.

Practitioner checklist

• Inventory every secret store and every principal with read rights, including shadow vaults.
• Remove read grants at account, project, folder or organisation scope; grant per secret or per vault.
• Move all Azure Key Vaults to the Azure RBAC permission model and restrict Contributor on vaults.
• Enable rotation with a tested rollback: AWSPREVIOUS in AWS, previous version in Azure and Google.
• Set expiry dates on Azure secrets and confirm a subscriber handles every Google rotation topic.
• Collect read events centrally and alert on bulk reads and first-time readers.
• Enable soft-delete and purge protection where keys are held; restrict purge and destroy rights.
• Match client cache TTLs to rotation, with a forced refresh on authentication failure.
• Replace stored cloud keys with managed identities, roles or federation wherever the target supports it.

Standards and references

• AWS: Lambda rotation functions (Secrets Manager User Guide)
• AWS: Secrets Manager CloudTrail log entries
• Microsoft Learn: Provide access to Key Vault keys, certificates and secrets with Azure RBAC
• Microsoft Learn: Azure Key Vault soft-delete overview
• Google Cloud: Secret Manager access control with IAM
• Google Cloud: Secret Manager rotation schedules
• MITRE ATT&CK: Cloud Secrets Management Stores
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Secrets Management Guide · Secret Sprawl Measurement Guide · Top 10 NHI Risks · Cloud Workload Identity Guide · Leaked Credential Response Playbook