Why Sync Secrets Across Clouds

Most organizations don’t run multi-cloud by choice. It happens organically. An acquisition brings AWS workloads into an Azure-first organization. A specific service (ML training, data warehousing, CDN) is cheaper or better on a different provider. A compliance requirement mandates geographic redundancy across cloud providers.

Whatever the reason, you end up with secrets that need to exist in more than one place. A database connection string that’s in Azure Key Vault also needs to be in AWS Secrets Manager because a Lambda function reads from the same database. An API key stored in GCP Secret Manager also needs to be in Azure because a Container App calls the same third-party API.

Managing this manually is where things go wrong. Someone rotates the secret in Azure but forgets to update AWS. The AWS copy expires or becomes stale. A failover event routes traffic to the AWS workload, which tries to use the old credential, and now your disaster recovery scenario has its own disaster.

The Secret Stores

Each cloud provider has its own secret management service. They’re conceptually similar but differ in important ways.

Azure Key Vault

  • Supports secrets, keys, and certificates as distinct object types
  • Secret versioning is automatic (each update creates a new version)
  • Soft delete and purge protection prevent accidental loss
  • Access via Azure RBAC or vault access policies
  • Regional service (each vault exists in one region)

AWS Secrets Manager

  • Secrets only (no native key or certificate management; AWS KMS handles keys, ACM handles certs)
  • Built-in rotation support with Lambda functions
  • Cross-region replication is a native feature
  • Access via IAM policies
  • Supports automatic rotation for RDS, Redshift, DocumentDB out of the box

GCP Secret Manager

  • Secrets with automatic versioning
  • Regional or global replication policies
  • Access via IAM roles
  • Secret versions can be individually enabled/disabled
  • No built-in rotation (you build it with Cloud Functions)

The Synchronization Problem

Keeping secrets in sync across these three systems requires solving several sub-problems:

1. Triggering sync on change

When a secret is updated in Azure Key Vault, how do you propagate the change to AWS and GCP?

Event-driven approach: Azure Key Vault emits events via Event Grid when a secret is updated (Microsoft.KeyVault.SecretNewVersionCreated). You can subscribe to this event and trigger an Azure Function or Logic App that writes the new value to AWS Secrets Manager and GCP Secret Manager.

# Pseudocode for a sync function triggered by Event Grid
def handle_secret_updated(event):
    vault_name = event.data["VaultName"]
    secret_name = event.data["ObjectName"]

    # Read new value from Azure Key Vault
    kv_client = SecretClient(vault_url=f"https://{vault_name}.vault.azure.net", credential=credential)
    secret_value = kv_client.get_secret(secret_name).value

    # Write to AWS Secrets Manager
    aws_client = boto3.client("secretsmanager", region_name="eu-west-1")
    aws_client.put_secret_value(SecretId=secret_name, SecretString=secret_value)

    # Write to GCP Secret Manager
    gcp_client = secretmanager.SecretManagerServiceClient()
    gcp_client.add_secret_version(
        request={"parent": f"projects/my-project/secrets/{secret_name}", "payload": {"data": secret_value.encode()}}
    )

Polling approach: A scheduled job reads secrets from the source (Azure Key Vault) and compares versions with the target stores. If a newer version exists, it propagates. This is simpler but introduces latency.

2. Authentication across clouds

Your sync process needs credentials for all three clouds. This creates a chicken-and-egg problem: you’re syncing secrets, but you also need secrets to do the syncing.

Best practice: Use managed identity or workload identity federation wherever possible.

  • The sync process running in Azure uses a Managed Identity to access Key Vault.
  • For AWS access, use OIDC federation between Azure AD and AWS IAM (no static AWS access keys).
  • For GCP access, use workload identity federation with Azure AD as the identity provider.

This eliminates static cross-cloud credentials, which would themselves need rotation.

3. Secret naming and mapping

Secret names don’t always map 1:1 across clouds. Azure Key Vault allows hyphens but not underscores. AWS Secrets Manager allows both. GCP Secret Manager allows underscores but not hyphens in some contexts.

You need a mapping layer:

  • my-database-password in Azure Key Vault
  • my-database-password in AWS Secrets Manager
  • my_database_password in GCP Secret Manager

Or adopt a naming convention that works across all three (alphanumeric with hyphens only).

4. Handling failures and drift

What happens when the sync to AWS succeeds but GCP fails? You now have three secret stores with inconsistent values. Your sync process needs:

  • Retry logic with exponential backoff
  • Drift detection that periodically verifies all stores have the same version
  • Alerting when sync fails or drift is detected
  • Audit logging for every sync operation (who, when, what, outcome)

5. Selective sync

Not every secret needs to be everywhere. You want to sync the database connection string used by workloads in all three clouds, but you don’t want to sync the Azure-specific App Registration credential to AWS. Pattern-based selection (regex or tags) lets you control which secrets are synced where.

Building It Yourself

A minimal sync pipeline involves:

  1. An Azure Function triggered by Event Grid
  2. Cross-cloud credentials (preferably via workload identity federation)
  3. Error handling and retry logic
  4. A mapping configuration (which secrets go where)
  5. Drift detection (a scheduled job comparing versions)
  6. Audit logging

This is achievable. The Azure Function is maybe 200 lines of Python. The complexity isn’t in any single piece; it’s in handling the edge cases reliably over time. What happens when GCP Secret Manager is briefly unavailable? When someone updates a secret directly in AWS, bypassing the sync? When your Event Grid subscription drops events because of a networking blip?

Production-grade sync requires handling all of these. It’s a meaningful engineering investment to get right and keep right.

The CertifyClouds Approach

CertifyClouds includes multi-cloud secret sync as part of the Pro tier. The approach:

  1. Configure target stores by providing AWS and GCP credentials (or workload identity federation configs)
  2. Select secrets to sync using regex patterns or manual selection per vault
  3. Automatic propagation on every rotation or manual secret update in Azure Key Vault
  4. Drift detection runs on a schedule and alerts if any target store has a stale value
  5. Full audit trail for every sync operation

Because sync is integrated with the rotation engine, the typical workflow is: rotate a secret in Azure, CertifyClouds propagates the new value to all configured cloud targets, verifies the propagation, and logs the entire operation. One action, all clouds updated.

If you’re running workloads across Azure and at least one other cloud, and you have secrets that need to exist in multiple places, multi-cloud sync eliminates the manual propagation step that’s responsible for most cross-cloud credential incidents. Try CertifyClouds Pro with a 30-day free trial.

Further Reading